User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-gb) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:188.8.131.52) Gecko/20100401 Firefox/3.6.3 I've recently noticed something very odd with DOMContentLoaded - if you have a large document which takes a while to load, but the browser shows a link while the page is still loading which is clicked upon by the user, then DOMContentLoaded fires! It takes you to the link, but only after listeners attached to the event are fired - and they expect the DOM to be loaded, which it isn't.... Here is an example of this in action: http://sprymedia.co.uk/media/misc/gecko/document_ready.php . The page has a sleep(5) at the bottom of it, so click the link within 5 seconds to see the alert show up before the document has loaded. This occurs in both Firefox and Webkit, so presumably some implementation matching going on. Furthermore, testing it in IE shows something similar (but presumably window.onload?). I've not been able to reproduce this in Minefield ( Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100525 Minefield/3.7a5pre ) because the page content won't display before the DOMContentLoaded has fired (perhaps itself a bug?). Shipping 3.6.3 displays the content as it is loading, and therefore this bug is reproducible. Possibly related to bug 478277? Reproducible: Always Steps to Reproduce: 1. Click a link before document has fully loaded Actual Results: DOMContentLoaded will be fired Expected Results: It seems odd that the DOM ready event is fired, when the HTML for the page hasn't been fully loaded - and is about to be navigated away from! I would not have expected this to occur.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206pre) Gecko/20100522 Namoroka/3.6.5pre With the latest trunk nightly build I get only as result: To late - document loaded. So it is not even possible to test or reproduce. http://nightly.mozilla.org/
> because the page content won't display before the DOMContentLoaded has fired > (perhaps itself a bug?) Sounds like it. Henri? In general, DOMContentLoaded fires when the parser is done, by definition. It doesn't matter if that happened because of a stop() call telling the parser to stop right now (which is what navigation does). It would also fire if the user hit the stop button, for that matter. What's odd here, exactly? And given that UAs agree on this, what would be the benefits of changing it (and likely breaking sites in the process)?
> I couldn't see a specification for DOMContentLoaded The closest thing to it is http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end but that seems to also require firing onload. What happens when a navigation is canceled seems to be wholly undefined. More realistically, the only specification for it is the actual implementation. > Is there any method by which I can tell if DOMContentLoaded has fired before > the DOM has fully loaded Not obviously... Of course neither can the browser; we have no way to tell whether your server really managed to send all the data you wanted it to send for the page, for example. So if your code is going to be robust in the face of network errors it needs to handle this sort of situation anyway.
> because the page content won't display before the DOMContentLoaded has fired > (perhaps itself a bug?) Filed as bug 568470.
I can still reproduce this bug in Firefox 20 ! As described here https://developer.mozilla.org/en-US/docs/DOM/Mozilla_event_reference/DOMContentLoaded The DOMContentLoaded event is fired when the document has been _completely_ loaded and parsed. So, this bug should be fixed IMO. Thanks.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.