82931 2012-04-02 13:03:22 -0700 DOMContentLoaded and load events should fire asynchronously 2022-08-20 16:20:32 -0700 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 jochen webkit-unassigned abarth ahmad.saleem792 ap bfulgham cdumez rniwa tkent oldest_to_newest 593729 0 jochen 2012-04-02 13:03:22 -0700 According to http://www.whatwg.org/specs/web-apps/current-work/#the-end step 4 and step 7, the DOMContentLoaded and load events should be fired asynchronously. Currently, they're both fired synchronously. Firefox seems to do this, all other browsers I tested (WebKit nightly, Opera 11, IE9) send the events synchronously We could either push for an update to the spec, or send the signal asynchronously as well. The latter would allow for firing all events during DOM mutation asynchronously, without sending events that happen during DOM parsing after the load event (see e.g. issue 82778) 593740 1 abarth 2012-04-02 13:19:09 -0700 Can you attach the test you're using? I'm not sure what you mean when you say we fire the load event synchronously. Often the load event fires due to data coming in from the network, which happens asynchronously. 593751 2 135167 jochen 2012-04-02 13:26:05 -0700 Created attachment 135167 test case That's my (lame) test-case. On Firefox, the timeout and load event come in an arbitrary order (reload a view times). On all other browsers I tested, load is always first. 593752 3 abarth 2012-04-02 13:27:55 -0700 That's not a good test case. There's no necessary relation between when those events fire. For example, transfer the HTML document with chunked encoding and make the server sleep for a minute between the </div> and the </body>. All browsers will fire the timeout before the load event in that case. 593777 4 jochen 2012-04-02 13:37:20 -0700 (In reply to comment #1) > Can you attach the test you're using? I'm not sure what you mean when you say we fire the load event synchronously. Often the load event fires due to data coming in from the network, which happens asynchronously. I read the spec as follows: between step 1 (set the document readiness to interactive) and step 4 (fire DOMContentLoaded event), we should drop back to the message loop in any case. If there are no scripts to be run when the documented finished parsing, we won't spin the message loop same between steps 4 and 7 593836 5 jochen 2012-04-02 14:17:49 -0700 I chatted with Adam a bit, and we both agree that the test case is lame. We considered making events that are fired asynchronously but should come before the load event could just delay the load event, but this "delay" is done between the DOMContentLoaded and the load event, so it would be still observable that the events are fired in the wrong (as in not conforming to the spec) order. Fixing this probably requires some non-trivial changes to FrameLoader, as it triggers e.g. DOMContentLoaded (fired in Document::finishedParsing) by invoking FrameLoader::finishedParsing in FrameLoader::stopLoading and then FrameLoader continues to mess with the document and its parser. 593850 6 135188 ojan 2012-04-02 14:31:28 -0700 Created attachment 135188 slightly better test case 593898 7 rniwa 2012-04-02 15:08:09 -0700 (In reply to comment #0) > According to http://www.whatwg.org/specs/web-apps/current-work/#the-end step 4 and step 7, the DOMContentLoaded and load events should be fired asynchronously. Currently, they're both fired synchronously. > > Firefox seems to do this, all other browsers I tested (WebKit nightly, Opera 11, IE9) send the events synchronously I'm not certain if we want to change our behavior then. It seems like there's some confusion here due to the bad test case. Could someone summarize the current state of this bug? (e.g. what's wrong with our current behavior, other browsers' behaviors, and possible solutions). 593967 8 jochen 2012-04-02 16:05:38 -0700 (In reply to comment #7) > (In reply to comment #0) > > According to http://www.whatwg.org/specs/web-apps/current-work/#the-end step 4 and step 7, the DOMContentLoaded and load events should be fired asynchronously. Currently, they're both fired synchronously. > > > > Firefox seems to do this, all other browsers I tested (WebKit nightly, Opera 11, IE9) send the events synchronously > > I'm not certain if we want to change our behavior then. > note that this assessment was based on a poor test, so it might as well be wrong. > It seems like there's some confusion here due to the bad test case. Could someone summarize the current state of this bug? (e.g. what's wrong with our current behavior, other browsers' behaviors, and possible solutions). The main issue is that if you create an asynchronous event either before the DOMContentLoaded event, or between the DOMContentLoaded event and the load event (depending on which code path is executed), the said event will not be fired before DOMContentLoaded or load respectively. Lacking a good test case, it's hard to describe what other browsers are doing. A possible solution would be to clean up all code paths such that - there's no sync code path from firing DOMContentLoaded to firing load (Document::finishedParsing to Document::implicitClose) - there's no sync code path from setting the document's readiness to interactive to firing DOMContentLoaded (HTMLDocumentParser::prepareToStopParsing to Document::finishedParsing) 593986 9 rniwa 2012-04-02 16:28:30 -0700 (In reply to comment #8) > The main issue is that if you create an asynchronous event either before the DOMContentLoaded event, or between the DOMContentLoaded event and the load event (depending on which code path is executed), the said event will not be fired before DOMContentLoaded or load respectively. > > Lacking a good test case, it's hard to describe what other browsers are doing. How can we be talking about fixing a "bug" when we don't even know what we're testing. We need to figure out what other browsers are doing first, or else this whole discussion doesn't lead us anywhere. 594036 10 ojan 2012-04-02 17:00:46 -0700 (In reply to comment #9) > (In reply to comment #8) > > The main issue is that if you create an asynchronous event either before the DOMContentLoaded event, or between the DOMContentLoaded event and the load event (depending on which code path is executed), the said event will not be fired before DOMContentLoaded or load respectively. > > > > Lacking a good test case, it's hard to describe what other browsers are doing. > > How can we be talking about fixing a "bug" when we don't even know what we're testing. We need to figure out what other browsers are doing first, or else this whole discussion doesn't lead us anywhere. That's nice in theory. In practice, browsers don't give a consistent set of APIs for determining how they behave here. All the tests that I've been able to come up with are racy and make it hard to tell definitively what a browser does. I'm open to suggestions for how to test this better, but we should either try to match the spec or get the spec changed. 1450123 11 rniwa 2018-08-14 15:45:00 -0700 Latest spec: https://html.spec.whatwg.org/multipage/parsing.html#stop-parsing 1890998 12 ahmad.saleem792 2022-08-12 14:37:44 -0700 Latest requests across browsers: *** Safari 15.6 on macOS 12.5 *** [object HTMLBodyElement] DOMContentLoaded load focus postMessage *** Safari Technical Preview 151 **** [object HTMLBodyElement] DOMContentLoaded load focus postMessage *** Chrome Canary 106 *** [object HTMLBodyElement] focus postMessage DOMContentLoaded load *** Firefox Nightly 105 *** [object HTMLBodyElement] focus DOMContentLoaded load postMessage ________ I am not sure on web-spec but just wanted to posted updated results. I used "slightly better.." test case. Thanks! 135167 2012-04-02 13:26:05 -0700 2012-04-02 13:26:05 -0700 test case test.html text/html 260 jochen PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KPHNjcmlwdD4KZnVuY3Rpb24gbG9nKG1zZykg ewogICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ2xvZycpLmlubmVySFRNTCArPSBtc2cgKyAn PGJyPic7Cn0KCm9ubG9hZCA9IGZ1bmN0aW9uKCkgewogICAgbG9nKCdsb2FkJyk7Cn0KCnNldFRp bWVvdXQoZnVuY3Rpb24oKSB7IGxvZygndGltZW91dCcpOyB9LCAwKTsKPC9zY3JpcHQ+CjxkaXYg aWQ9J2xvZyc+PC9kaXY+CjwvYm9keT4KPC9odG1sPgo= 135188 2012-04-02 14:31:28 -0700 2012-04-02 14:31:28 -0700 slightly better test case scratch.html text/html 1026 ojan PCFEb2NUeXBlIEhUTUw+Cjxib2R5IG9ubG9hZD0ibG9nZ2VyLmlubmVySFRNTCArPSAnbG9hZDxi cj4nIj4KU2hvdWxkIHNlZSAidGltZW91dCIgcHJpbnRlZCBiZWZvcmUgImZvY3VzIi4KPGRpdiBp ZD0ibG9nZ2VyIj48L2Rpdj4KPHNjcmlwdD4KdmFyIGlucHV0ID0gZG9jdW1lbnQuY3JlYXRlRWxl bWVudCgnaW5wdXQnKTsKaW5wdXQuc2V0QXR0cmlidXRlKCdhdXRvZm9jdXMnLCAndHJ1ZScpOwps b2dnZXIgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnbG9nZ2VyJyk7Cgp3aW5kb3cub25tZXNz YWdlID0gZnVuY3Rpb24oKSB7CiAgICBsb2dnZXIuaW5uZXJIVE1MICs9ICdwb3N0TWVzc2FnZTxi cj4nOwp9Cgpkb2N1bWVudC5hZGRFdmVudExpc3RlbmVyKCdET01Db250ZW50TG9hZGVkJywgZnVu Y3Rpb24oKSB7CiAgICBsb2dnZXIuaW5uZXJIVE1MICs9ICdET01Db250ZW50TG9hZGVkPGJyPic7 Cn0sIHRydWUpOwppbnB1dC5vbmZvY3VzID0gZnVuY3Rpb24oKSB7IGxvZ2dlci5pbm5lckhUTUwg Kz0gJ2ZvY3VzPGJyPicgfTsKCmRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoaW5wdXQpOwoKaWYg KHdpbmRvdy5zZXRJbW1lZGlhdGUpIHsKICAgIHdpbmRvdy5zZXRJbW1lZGlhdGUoZnVuY3Rpb24o KSB7CiAgICAgICAgbG9nZ2VyLmlubmVySFRNTCArPSAnc2V0SW1tZWRpYXRlJzsKICAgIH0pOwp9 IGVsc2UgewogICAgLy8gRWZmZWN0aXZlbHkgdGhpcyBxdWV1ZSdzIGEgdGFzayBpbiBhbGwgYnJv d3NlcnMuIFRoZSBzcGVjIGRvZXNuJ3QgcmVxdWlyZSB0aGF0IHRob3VnaCwKICAgIC8vIHNvIHRo YXQgbWlnaHQgaW52YWxpZGF0ZSB0aGlzIHRlc3QgY2FzZS4gSUUgaGFzIHNldEltbWVkaWF0ZSB0 byBxdWV1ZSBhIHRhc2ssIGJ1dCBvdGhlcgogICAgLy8gYnJvd3NlcnMgZG9uJ3QgaW1wbGVtZW50 IGl0LgogICAgd2luZG93LnBvc3RNZXNzYWdlKCdtc2cnLCAnKicpOwp9Cgpsb2dnZXIuaW5uZXJI VE1MICs9IGRvY3VtZW50LmFjdGl2ZUVsZW1lbnQgKyAnPGJyPic7Cjwvc2NyaXB0Pgo8L2JvZHk+