568050 - DOMContentLoaded: firing before document loaded, upon user action

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P5)

Description

[Allan Jardine]

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:1.9.2.3) 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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.5pre) 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/

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Allan Jardine]

I fully agree that there is an argument which could say that the DOMContentLoaded event should fire when the full limit of the DOM that is available, and that scripts should have the option of acting on that. What I see as odd is that the DOM has not fully loaded, nor is it going to be used in the case of a link being clicked, since the browser is navigating away from the page.

From the MDC description ( https://developer.mozilla.org/en/Gecko-Specific_DOM_Events ): "Fired on a Window object when a document's DOM content is finished loading". As a Javascript developer I would have expected that this event would only fire when the DOM has loaded - otherwise scripts are going to run (like the one which allowed me to see this issue) and expect elements to be in the DOM which are not, and thus throw an error.

I couldn't see a specification for DOMContentLoaded - is there anything more than just the MDC description?

Is there any method by which I can tell if DOMContentLoaded has fired before the DOM has fully loaded, and thus act accordingly?

The Webkit bug for this issue: https://bugs.webkit.org/show_bug.cgi?id=39683

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Allan Jardine]

I encountered this issue because I was making my code recognise and give warnings on faults. What I've done is to look for the elements that are required in the document, and if they are not present when the document is 'ready' an alert() will be displayed to tell the developer and allow them to correct this.

This is very useful, but can cause the effect that I've described when an end user takes the action of clicking on an element before the page load has completed, then they will see this alert and it will stop the page loading until they confirm the alert.

If unload were to fire before the DOMContentLoaded event, then in Javascript a flag could be set to indicate what is happening. That might be one way around it - however, unload doesn't appear to be firing at all under these circumstances, never mind before DOMContentLoaded!

Comment 6

[Boris Zbarsky [:bzbarsky]]

> because the page content won't display before the DOMContentLoaded has fired
> (perhaps itself a bug?)

Filed as bug 568470.

Comment 7

[Jimmy Gilles]

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.

Comment 8

[Firefox Bug Husbandry Bot]

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.