Last Comment Bug 481534 - DOMContentLoaded fires before CSS has finished loading
: DOMContentLoaded fires before CSS has finished loading
Status: VERIFIED INVALID
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
http://cufon.shoqolate.com/tests/ff3-...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-04 16:37 PST by Simo Kinnunen
Modified: 2009-07-22 20:25 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Simo Kinnunen 2009-03-04 16:37:26 PST
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
Comment 1 Dão Gottwald [:dao] 2009-03-05 14:31:01 PST
This is expected behavior. Stylesheets are loaded asynchronously and don't block the construction of the DOM tree.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2009-03-06 07:18:32 PST
Yep.  DOMContentLoaded fires when parsing is complete and the DOM is ready, and stylesheets (unlike scripts) do not block parsing.
Comment 3 Simo Kinnunen 2009-03-06 08:27:09 PST
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.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2009-03-06 08:30:35 PST
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...

Note You need to log in before you can comment on or make changes to this bug.