234730 2021-12-28 14:18:08 -0800 load and beforeunload window event listeners callback order different in Safari than Chrome and Firefox 2023-06-07 08:18:07 -0700 1 1 1 Unclassified WebKit DOM Safari 15 All All NEW BrowserCompat, InRadar P2 Normal --- 1 opendarwin webkit-unassigned cdumez simon.fraser webkit-bug-importer oldest_to_newest 1827123 0 448055 opendarwin 2021-12-28 14:18:08 -0800 Created attachment 448055 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. 1827132 1 opendarwin 2021-12-28 15:02:39 -0800 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. 1828096 2 webkit-bug-importer 2022-01-04 14:19:46 -0800 <rdar://problem/87114687> 1828361 3 gsnedders 2022-01-05 12:55:10 -0800 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. 1828373 4 opendarwin 2022-01-05 13:22:11 -0800 (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. 1828633 5 cdumez 2022-01-06 09:04:08 -0800 (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. 448055 2021-12-28 14:18:08 -0800 2021-12-28 14:18:08 -0800 Sample html demonstrating the inconsistency index.html text/html 560 opendarwin PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+Cgk8bWV0YSBodHRwLWVxdWl2 PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+Cgk8dGl0 bGU+d2luZG93IGV2ZW50IHRlc3Q8L3RpdGxlPgo8L2hlYWQ+Cjxib2R5Pgo8aDE+d2luZG93IGV2 ZW50IHRlc3Q8L2gxPgo8c2NyaXB0Pgp3aW5kb3cuYWRkRXZlbnRMaXN0ZW5lcigibG9hZCIsICgp ID0+IHsgY29uc29sZS5sb2coImxvYWQgZmFsc2UiKTsgfSwgZmFsc2UpOwp3aW5kb3cuYWRkRXZl bnRMaXN0ZW5lcigibG9hZCIsICgpID0+IHsgY29uc29sZS5sb2coImxvYWQgdHJ1ZSIpOyB9LCB0 cnVlKTsKd2luZG93LmFkZEV2ZW50TGlzdGVuZXIoImJlZm9yZXVubG9hZCIsICgpID0+IHsgY29u c29sZS5sb2coImJlZm9yZXVubG9hZCBmYWxzZSIpOyB9LCBmYWxzZSk7CndpbmRvdy5hZGRFdmVu dExpc3RlbmVyKCJiZWZvcmV1bmxvYWQiLCAoKSA9PiB7IGNvbnNvbGUubG9nKCJiZWZvcmV1bmxv YWQgdHJ1ZSIpOyB9LCB0cnVlKTsKPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo=