Bug 82931 – DOMContentLoaded and load events should fire asynchronously

• Component: UI Events
• Status: NEW

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)

[Adam Barth]

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.

Created attachment 135167 [details]
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.

[Adam Barth]

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.

(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

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.

[Ojan Vafai]

Created attachment 135188 [details]
slightly better test case

[Ryosuke Niwa]

(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).

(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)

[Ryosuke Niwa]

(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.

[Ojan Vafai]

(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.

[Ryosuke Niwa]

Latest spec: https://html.spec.whatwg.org/multipage/parsing.html#stop-parsing

[Ahmad Saleem]

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!