1492446 - Change event listener invocation order (fire capturing listeners on target before non-capturing ones)

Status: RESOLVED DUPLICATE of bug 1731504

(Core :: DOM: Events, enhancement, P3)

Description

[Anne (:annevk)]

As discussed in https://github.com/whatwg/dom/issues/685 and proposed for incorporation in the DOM standard in https://github.com/whatwg/dom/pull/686, it's highly likely event dispatch behavior will be slightly adjusted. Both Chrome and Safari have landed a patch for this new behavior and we'll learn about any web compatibility issues through them.

Proposed tests are https://github.com/web-platform-tests/wpt/pull/13030 and https://github.com/web-platform-tests/wpt/pull/13031.

Your review and input on all of this is appreciated.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Still waiting for the wpt tests to get merged to m-c. That would make testing this quite a bit easier.

Comment 2

[Anne (:annevk)]

https://github.com/web-platform-tests/wpt/pull/16307 has more tests. https://github.com/whatwg/dom/pull/750 has a further change to the standard.

Comment 3

[Anne (:annevk)]

https://github.com/web-platform-tests/wpt/pull/16358 has yet more tests.

Comment 4

[Michał Gołębiowski-Owczarek [:mgol]]

It seems to me that Chrome didn't implement the change fully as specified in the issue title. See the test case:

https://jsbin.com/yepukid/1/edit?js,output

If you click on the "Click" word, what gets logged in the console in Chrome 80 is the following:

bubble 1, phase: 2
capture 1, phase: 2
bubble 2, phase: 2
capture 2, phase: 2

The same happens in Firefox 73. If you click on "me", the order changes as the target is the inner span:

capture 1, phase: 1
capture 2, phase: 1
bubble 1, phase: 3
bubble 2, phase: 3

On the other hand, Safari always keeps the capture-before-bubble order; e.g. when you click on "Click":

capture 1, phase: 2
capture 2, phase: 2
bubble 1, phase: 2
bubble 2, phase: 2

Safari introduced this change in version 12.0 or 12.1. To me the Safari behavior makes a lot more sense than the current Firefox/Chrome one and I had an impression from the discussion that it's an intended change.

Comment 5

[Michał Gołębiowski-Owczarek [:mgol]]

For posterity, the test case code is as follows:

HTML:
<div id="button">Click <span id="span">me</span></div>

JS:

var button = document.getElementById('button');

button.addEventListener('click', function (ev) {
    console.log('bubble 1, phase:', ev.eventPhase);
});
button.addEventListener('click', function (ev) {
    console.log('capture 1, phase:', ev.eventPhase);
}, true);
button.addEventListener('click', function (ev) {
    console.log('bubble 2, phase:', ev.eventPhase);
});
button.addEventListener('click', function (ev) {
    console.log('capture 2, phase:', ev.eventPhase);
}, true);

Comment 6

[Anne (:annevk)]

Could you file a bug at https://crbug.com/new? It sounds like https://github.com/whatwg/dom/issues/685#issuecomment-422640186 was not entirely accurate in that case. If that scenario is not covered by the tests it would be great if you could contribute it as web-platform-tests as well.

Comment 7

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to Anne (:annevk) from comment #6)

Could you file a bug at https://crbug.com/new? It sounds like https://github.com/whatwg/dom/issues/685#issuecomment-422640186 was not entirely accurate in that case. If that scenario is not covered by the tests it would be great if you could contribute it as web-platform-tests as well.

I think there's already a WPT for that; see:
https://github.com/web-platform-tests/wpt/blob/master/dom/events/Event-dispatch-order-at-target.html

Only Safari passes both assertions:
https://wpt.fyi/results/dom/events/Event-dispatch-order-at-target.html

I'll file a Chromium bug later.

Comment 8

[Michał Gołębiowski-Owczarek [:mgol]]

Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1052152

Comment 9

[Anne (:annevk)]

Thanks Michał!

Comment 10

[Anne (:annevk)]

smaug, what do you think about fixing this? Only Safari is doing this today, but without this we reveal the shadow tree.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Yes, I'll try to get to this asap. Kick me if I don't get :)

Comment 13

[taylor]

kick (just kidding)

I just wanted to pop in and ask if this is still in the works or on the table? I sadly ran into some negative side effects of this issue which led me down a long rabbit hole and eventually here. We developed a seemingly reliable workaround to the problem (place a capture-phase listener on a parent element to ensure execution before bubble-phase listeners), but of course fixing at the source would be preferred.

Cheers,
Taylor

Comment 14

[christian]

Any news on this?
It's been 3 years, Firefox is the only browser who does it backward now, when can we expect a fix?

Comment 15

[Anne (:annevk)]

Given the number of needinfo's Olli has, perhaps Edgar or Kagami is willing to take a look at this?

Comment 16

[Edgar Chen [:edgar]]

I could take a look, probably early next week.

Comment 17

[Edgar Chen [:edgar]]

bug 1731504 fixes this, verified on the latest Nightly