Capturing event listeners are called during bubbling phase for shadow hosts

[rniwa]

We have a bug report saying that WebKit fires event listeners with capture flag set to true during bubbling phase.

Consider the following DOM:

const hostParent = document.createElement('section');
hostParent.id = 'hostParent';
hostParent.innerHTML = '<div id="host"></div>';
const host = hostParent.firstChild;
const shadowRoot = host.attachShadow({mode: 'closed'});
shadowRoot.innerHTML = '<p id="parent"><span id="target"></span></p>';
...
target.dispatchEvent(new CustomEvent('test', {detail: {}, bubbles: true, composed: true});

Then the event listeners on target, parent, host, and hostParent are invoked in the following order on WebKit & Chrome:

• hostParent, capturing, eventPhase: CAPTURING_PHASE
• parent, capturing, eventPhase: CAPTURING_PHASE
• target, capturing, eventPhase: AT_TARGET
• target, non-capturing, eventPhase: AT_TARGET
• parent, non-capturing, eventPhase: BUBBLING_PHASE
• host, capturing, eventPhase: AT_TARGET
• host, non-capturing, eventPhase: AT_TARGET
• hostParent, non-capturing, eventPhase: BUBBLING_PHASE

As far as I can tell, the current behavior of WebKit & Chrome is in accordance with the latest DOM specification. What happens is that step 5 (event path construction) in dispatching an event ends up appending an tuple/struct (we should probably stick with either term, btw) with target set to null. In step 14, we only invoke event listeners with capture flag set if target is null, meaning that shadow hosts' event listeners with capture flag set would NOT be called. Then in step 15, we set eventPhase to AT_TARGET and invoke event listeners. Because the concept to inner invoke an event listener doesn't skip event listeners with capture flag set to true when the event phase is AT_TARGET, we end up firing capturing event listeners during bubbling.

[rniwa]

@annevk @hayatoito @smaug----

[rniwa]

I think we should update the spec to match what Gecko implemented which ends up invoking event listeners in the following order for the example:

• hostParent, capturing, eventPhase: CAPTURING_PHASE
• host, capturing, eventPhase: AT_TARGET
• parent, capturing, eventPhase: CAPTURING_PHASE
• target, capturing, eventPhase: AT_TARGET
• target, non-capturing, eventPhase: AT_TARGET
• parent, non-capturing, eventPhase: BUBBLING_PHASE
• host, non-capturing, eventPhase: AT_TARGET
• hostParent, non-capturing, eventPhase: BUBBLING_PHASE

[annevk]

I agree that what Gecko does looks a lot better and I've created #686 to align with it. @stramel, I acknowledged you as "Michael Stramel". Please let me know if you'd prefer a different name there.

I'm somewhat surprised we don't have good test coverage for this.

[stramel]

@annevk That works for me! Thanks!

@rniwa Thank you for the detailed explanation of what was happening and looking into it!

[hayatoito]

I remember there were some discussions around this area between @annevk and Dimitri (and maybe including me?), however, I don't recall it.

Let me try to find the discussions in the past. Maybe there is a reason for the current behavior.

So please don't proceed this until we could get more insights from the past discussions.

[annevk]

@hayatoito ah yes, #237 discusses it. It does seem this needs some more research.

[hayatoito]

@annevk Thanks! That's exactly what I've tried to find. Let me take a look.

[rniwa]

Okay according to #237, we want to be invoking both capturing & bubbling event listeners during pebble phase.

Presumably, this was agreed to in order to let non-capturing event listeners inside the shadow tree to do the necessary work before the event dispatched outside the shadow tree.

However, it makes no sense whatsoever that the capturing event listeners on ancestors of a shadow host are getting invoked BEFORE capturing event listeners are invoked on the target inside a shadow tree.

[hayatoito]

It looks I've changed the behavior here, which was originally requested by @azakus (Daniel Freedman).

Maybe we would like to hear more opinions or feedback from web authors before changing the behavior because the current behavior has been there for years, and the change would be a breaking change for us, especially existing web components frameworks.

@azakus, we'd appreciate if you could share your insights.

[annevk]

So the reason we went with the current model as outlined in #237 is because once you reach a target, all registered listeners get invoked in order, regardless of their capture boolean value. Due to shadow trees creating multiple targets, targets outside the shadow tree would first get their capture listeners invoked, and then their bubble listeners. So you could observe there is a shadow tree underneath if an earlier registered bubble listener is invoked before a capture listener.

It would make some sense to me if we changed the model and always invoked capture listeners before bubble listeners, but I don't know how compatible that would be.