Composed and non bubbling event semantic dispatched in shadow tree

[pmdartus]

What is the expected behavior for a composed and non-bubbling event when dispatched inside a shadow tree?

When an event listener is attached to the host element, and a composed and non-bubbling event is dispatched within a shadow tree, the listener attached on the host element is invoked. Here is an example: https://jsfiddle.net/pmdartus/6ft9gkc4/7/

This behavior is consistent on all the browsers implementing shadow DOM.

As far as I understand the recent changes made to the dispatch event algorithm (#686), the behavior changed and now the event will only invoke the host element event handler if the event bubbles (step 14). Is it the new expected behavior, or did I missed something?

---

Regardless of the outcome of this question, I think it worth adding more details to the non-normative section about composed.

[annevk]

So the problem is that we created events that only have a capture phase from the view of certain trees.

I think what's needed here is these changes:

1. Step 5.14 of https://dom.spec.whatwg.org/#concept-event-dispatch should not be conditional upon "If event’s bubbles attribute is true".
2. Step 5.14.2 should be conditional upon "If event’s bubbles attribute is true" and use continue there to go to the next struct.

This would make step 14 read:

For each struct in event’s path:

1. If struct’s target is non-null, then set event’s eventPhase attribute to AT_TARGET.
2. Otherwise:
   1. If event’s bubbles attribute is false, then continue.
   2. Set event’s eventPhase attribute to BUBBLING_PHASE.
3. Invoke with struct, event, "bubbling", and legacyOutputDidListenersThrowFlag if given.

cc @whatwg/components

(As for composed, it affects building the event's path and that's it. It seems like you mostly didn't observe the event because you didn't have capture listeners.)

[pmdartus]

Those changes look reasonable to me. Thanks for the details @annevk.

[caridy]

As @pmdartus mentioned, the proposed changes look good, but I will like to get some clarification on why the current behavior was chosen in the first place. We discovered the issue described here while trying to test our synthetic shadow dom polyfill, and we were surprised by the behavior of all browsers. Why all composed events dispatched on the host elements in the event path regardless if the event bubbles or not? Seems counterintuitive, and leak internal implementation details of the component.

[annevk]

@caridy events have four phases: none, capturing, at target, and bubbling. Capturing and at target are always performed. If we did not perform at target for a composed event, it would actually leak that there was a component as the target for an event we could observe during capturing was not in our tree. (I realize this is the opposite of what you suggest, but it's unclear to me how you're arriving at your conclusion.)

[rniwa]

Capturing and at target are always performed.

Maybe we need capturing flag in EventInit which disables capturing phase as well. It is fundamentally weird that you can't dispatch an event within a component without it being observable outside of it since that leaks the implementation details of a component.

[annevk]

@rniwa that is what composed is for. By default an event's path doesn't cross the shadow boundary (except from something slotted into a shadow tree, but that's different).

[rniwa]

@annevk : oh, that's a good point. If the composed is set to false, we wouldn't have this issue.

[caridy]

here is a very concrete example of the problem:

<div>
    #shadowRoot 
       <div>
            <x-foo>

If component <x-foo> dispatches an custom event with { composed: true, bubbles: false } via this.dispatchEvent(), it is extremely confusing that the event is observable from the outer div, but it is not observable by the inner div. From the teachability point of view, how do you teach that? It breaks all intuitions as far as I can tell.

From the technical point of view, the leaking aspect of it is pretty bad because the only way you have to prevent an event from leaking is by listening for it at the host level (during construction time), and stop immediate propagation, and you have to do so for all events dispatched by any of your child components in order to control the leakage, and still, there is a possibility that the host was upgraded after a listener for the event was added by someone else, in which case, you have no ways to prevent the leakage.

[annevk]

@caridy if you use addEventListener(yourEventNameHere, yourHandlerHere, true) on the inner <div> it is observable there too. I'd like to refer back to my comment about event phases.

[annevk]

Fix at #750.