Bug 5122 – Need an equivalent of Mozilla's DOMContentLoaded event

• Component: DOM
• Status: RESOLVED FIXED

[Simon Willison]

It's extremely desirable to set up a JavaScript function to be executed as soon
as the DOM has loaded. window.onload is no good as it waits for all images on
the page to load as well.

Workarounds for this exist for both Mozilla and IE, as documented here:
http://dean.edwards.name/weblog/2005/09/busted/

A way of achieving this in Safari would be very welcome.

[Alexey Proskuryakov]

Actually, script defer, mentioned in the blog entry, does work in both Safari and Firefox. Try replacing init() with alert(0) - it does pop up at the expected moment. So, some other issue may be preventing the code from working.

Some comments to the blog entry indicate that DOMContentLoaded is substantially different from defer, though.

[Joost de Valk (AlthA)]

Reassigning to webkit-unassigned, to make sure more people see this.

[Joost de Valk (AlthA)]

Discussed this on IRC with ggaren and mjs, and it is a valid request.

[Beau Hartshorne]

There's a good discussion of defer here:
http://www.davidflanagan.com/blog/2006_01.html

[Daniel Peebles]

I'm working on it. Just writing a testcase for it, although I can only base my idea for its 'right' behavior on that of firefox... at the moment I consider it right if it gets triggered independently of external resources, and onload occurs after DOMContentLoaded... any other restrictions you can think of?

[Daniel Peebles]

Created attachment 6950 [details]
A patch that adds support for the DOMContentLoaded event 

Just added a few lines here and there. It appears to work the way it should, but "should" isn't very well defined. It does get triggered when the document finishes parsing, which appears to be the generally accepted contract for the event.

[Maciej Stachowiak]

Comment on attachment 6950 [details]
A patch that adds support for the DOMContentLoaded event 

In general this change looks really good, a few small comments (also mentioned on IRC):

- The test case doesn't need to do the fibonnacci thing, JS is single-threaded so that doesn't really add anything.

- The test case could check a few more things. For instance, it could load an external image or stylesheet or something, and verify that DOMContentLoaded fires before the subresource onload event (this isn't guaranteed, but in the layout test case it shouldn't be in cache). You could also check that the whole document is parsed by checking for instance that the last element of the document is there as expected.

- There's no need to specially filter this event like DOM mutation events, it is not gonna fire often enough to need the optimization.

You can probably get rid of this comment:

+    // I think this is the right place for the DOMContentLoaded trigger, but maybe not...

r- for these technicalities, can't wait to see the updated version.

[Daniel Peebles]

(In reply to comment #7)
> (From update of attachment 6950 [details] [edit])
> In general this change looks really good, a few small comments (also mentioned
> on IRC):
> 
> - The test case doesn't need to do the fibonnacci thing, JS is single-threaded
> so that doesn't really add anything.
> 
> - The test case could check a few more things. For instance, it could load an
> external image or stylesheet or something, and verify that DOMContentLoaded
> fires before the subresource onload event (this isn't guaranteed, but in the
> layout test case it shouldn't be in cache). You could also check that the whole
> document is parsed by checking for instance that the last element of the
> document is there as expected.
> 
> - There's no need to specially filter this event like DOM mutation events, it
> is not gonna fire often enough to need the optimization.
> 
> You can probably get rid of this comment:
> 
> +    // I think this is the right place for the DOMContentLoaded trigger, but
> maybe not...
> 
> r- for these technicalities, can't wait to see the updated version.
> 

ran into a really strange bug while trying to fix those, so I'll probably have it in by tomorrow :)

[Daniel Peebles]

My implementation of DOMContentLoaded causes odd behavior in DumpRenderTree, so I've filed another bug for that (7693.) I'm seeing if I can fix that right now :-/

[Arthur Langereis]

With bug 7693 resolved for over a year now, can you try to get DOMContentLoaded in again? I and several others would love to see this feature added in time for 3.0.

The current workaround for this is an ugly sniffer timer that checks the readyState property, a real event would be great. When Safari adds this, the relevant non-IE browsers will all support this. Sorry for the spam, it's just been very quiet here.

[Daniel Peebles]

Sorry, have been out of the loop for a while. I'll test my patch to make sure everything works and submit an updated patch in the next few days.

(In reply to comment #10)
> With bug 7693 resolved for over a year now, can you try to get DOMContentLoaded
> in again? I and several others would love to see this feature added in time for
> 3.0.
> 
> The current workaround for this is an ugly sniffer timer that checks the
> readyState property, a real event would be great. When Safari adds this, the
> relevant non-IE browsers will all support this. Sorry for the spam, it's just
> been very quiet here.
> 

[Mark Rowe (bdash)]

I'm working on cleaning up this patch.

[Mark Rowe (bdash)]

Created attachment 16468 [details]
Updated patch

[Maciej Stachowiak]

Comment on attachment 16468 [details]
Updated patch

DOMContentLoaded should probably be a generic event, not a MutationEvent.

[Mark Rowe (bdash)]

Created attachment 16469 [details]
Updated patch using Event and with faster layout test

[Maciej Stachowiak]

Comment on attachment 16469 [details]
Updated patch using Event and with faster layout test

r=me for feature-branch

[Eric Seidel (no email)]

This is a GIT diff, someone with GIT (likely bdash) will need to land it on fb.

[Mark Rowe (bdash)]

Eric, svn-apply handles git diffs just fine.

[Mark Rowe (bdash)]

That said, I'll hold onto this and land this a bit later on after trunk opens up.  I have a slightly tweaked version locally, so please do not land the patch on this bug :)

[Eric Seidel (no email)]

Comment on attachment 16469 [details]
Updated patch using Event and with faster layout test

Marking this patch as obsolete to remove it from the review queue.  (Since it's obsoleted by a patch on bdash's HD.)

[Eric Seidel (no email)]

Comment on attachment 16469 [details]
Updated patch using Event and with faster layout test

Bah, commit queue.  And that didn't do it.  Clearing flag.

[Eric Seidel (no email)]

Comment on attachment 16469 [details]
Updated patch using Event and with faster layout test

Also, (somewhat unrelated) I've heard rumors that "trunk" will be "feature-branch" soon anyway.

[Mark Rowe (bdash)]

Landed in r26101.