Bug 234730 – load and beforeunload window event listeners callback order different in Safari than Chrome and Firefox

• Status: NEW
• Component: DOM

[Jeff Johnson]

Created attachment 448055 [details]
Sample html demonstrating the inconsistency

The EventTarget.addEventListener() method has a boolean useCapture parameter:
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#parameters

This mostly works the same in all browsers. However, it works differently in Safari for some window events such as "load" and "beforeunload":
https://developer.mozilla.org/en-US/docs/Web/API/Window#events

The target of these events is the window object itself, so technically you could say there are no capturing or bubbling event phases.

Consider the following code:

window.addEventListener("load", () => { console.log("load false"); }, false);
window.addEventListener("load", () => { console.log("load true"); }, true);
window.addEventListener("beforeunload", () => { console.log("beforeunload false"); }, false);
window.addEventListener("beforeunload", () => { console.log("beforeunload true"); }, true);

In Safari, the above useCapture true listeners are called prior to the above useCapture false listeners. However, in Chrome and Firefox, these listeners are called in the order registered, as if the useCapture parameter were irrelevant.

I won't argue which behavior is "correct". I'm just noting that Safari is inconsistent with the other browsers.

[Jeff Johnson]

Tested on macOS 11.6.2 with Safari 15.2, Safari Technology Preview 137, Chrome 96, and Firefox 95. Also tested with Mobile Safari on iOS 15.2.

[Radar WebKit Bug Importer]

<rdar://problem/87114687>

[Sam Sneddon [:gsnedders]]

useCapture shouldn't be affecting event dispatch order; dom/events/Event-dispatch-order.html in WPT is meant to test this but clearly doesn't suffice.

[Jeff Johnson]

(In reply to Sam Sneddon [:gsnedders] from comment #3)
> useCapture shouldn't be affecting event dispatch order;
> dom/events/Event-dispatch-order.html in WPT is meant to test this but
> clearly doesn't suffice.

I'm happy to accept Safari's behavior as correct, and would file bugs against Chromium and Firefox, though perhaps someone more important than me would be more persuasive to them.

[Chris Dumez]

(In reply to Sam Sneddon [:gsnedders] from comment #3)
> useCapture shouldn't be affecting event dispatch order;
> dom/events/Event-dispatch-order.html in WPT is meant to test this but
> clearly doesn't suffice.

@Sam: Could you clarify why the event dispatch order should not be impacted by useCapture? I am looking at https://dom.spec.whatwg.org/#concept-event-dispatch and our implementation seems to match the spec:
1. First we Invoke with struct, event, "capturing", and legacyOutputDidListenersThrowFlag if given.
2. Then we Invoke with struct, event, "bubbling", and legacyOutputDidListenersThrowFlag if given.

From https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke, some listeners are skipped during each phase based on listener's "capture".

So it makes sense to me that we're calling the ones with useCapture=true first and then the ones with useCapture=false.