[Webkit-unassigned] [Bug 82931] DOMContentLoaded and load events should fire asynchronously

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=82931





--- Comment #8 from jochen at chromium.org  2012-04-02 16:05:38 PST ---
(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)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.