Closed Bug 481534 Opened 15 years ago Closed 15 years ago

DOMContentLoaded fires before CSS has finished loading

Categories

(Core :: DOM: Events, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: sorccu, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre

If a <link rel="stylesheet"> is not followed by a <script>, DOMContentLoaded will fire before the CSS file finishes loading.

Reproducible: Sometimes

Steps to Reproduce:
1. Open the first test case, http://cufon.shoqolate.com/tests/ff3-domready/script-link.html
2. An alert() will pop up with the results
3. Refresh and flush cache if necessary. The test may pass at times.
Actual Results:  
The default color of black rgb(0, 0, 0) is reported instead of the blue rgb(0, 0, 255) that was specified in the CSS file.

Expected Results:  
The color should match the one that was specified in the CSS file (eg. it should have been loaded).

Happens in Firefox 3.0.6 on OS X, but passes more often than it fails. Shift-reloading and then doing a normal reload reliably reproduces the issue.
Also happens in Firefox 3.1b1 on Windows 7.
The newest nightly 3.2a1pre on OS X fails almost every time.
Firefox 2 passes every time.

Firebug's net tab also shows the DOMContentLoaded event firing prematurely. The onload event on the other hand seems to work as it should.

Moving the <link rel="stylesheet"> above the <script> fixes the issue, as can be seen in the second test case:

http://cufon.shoqolate.com/tests/ff3-domready/link-script.html

Placing another <script> with some content in it (one space is enough) after the <link> also fixes the issue, as seen in the third test case:

http://cufon.shoqolate.com/tests/ff3-domready/script-link-script.html
This is expected behavior. Stylesheets are loaded asynchronously and don't block the construction of the DOM tree.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
Resolution: --- → INVALID
Yep.  DOMContentLoaded fires when parsing is complete and the DOM is ready, and stylesheets (unlike scripts) do not block parsing.
Status: RESOLVED → VERIFIED
I see. Sorry for the trouble then.

However I would be grateful if you could take a look at the following page, which includes 10MB worth of CSS (straight from /dev/urandom) and listens for the DOMContentLoaded event:

http://cufon.shoqolate.com/tests/ff3-domready/10MB.html

In Firefox 3.0.6 DOMContentLoaded will only fire after the CSS has been fully loaded. In fact the whole page won't even render before it's done. Does the <script> after the <link> somehow block parsing even though it isn't an external script? The behavior is the same in the latest nightly, too.
Yes.  Script execution (not loading) is what blocks parsing, because the script might do document.write.  Script execution blocks on stylesheet loads because scripts tend to ask for layout data that depends on stylesheets.

Pretty sure this is documented somewhere...
You need to log in before you can comment on or make changes to this bug.