Bug 5122

Summary: Need an equivalent of Mozilla's DOMContentLoaded event
Product: WebKit Reporter: Simon Willison <swillison@gmail.com>
Component: HTML DOMAssignee: Mark Rowe (bdash) <mrowe@apple.com>
Status: RESOLVED FIXED    
Severity: Enhancement CC: ap@webkit.org, gavin.sharp@gmail.com, ian@hixie.ch, mrowe@apple.com, pumpkingod@gmail.com, rvamerongen@xs4all.nl, webkit@andrewdupont.net
Priority: P2    
Version: 420+   
Hardware: Macintosh   
OS: Mac OS X 10.4   
URL: http://dean.edwards.name/weblog/2005/09/busted/
Bug Depends on: 7693    
Bug Blocks:    
Attachments:
Description Flags
A patch that adds support for the DOMContentLoaded event
mjs: review-
Updated patch
mjs: review-
Updated patch using Event and with faster layout test none

Description From 2005-09-24 17:13:14 PST
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.
------- Comment #1 From 2006-02-07 12:25:13 PST -------
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.
------- Comment #2 From 2006-02-13 15:56:24 PST -------
Reassigning to webkit-unassigned, to make sure more people see this.
------- Comment #3 From 2006-02-15 15:26:55 PST -------
Discussed this on IRC with ggaren and mjs, and it is a valid request.
------- Comment #4 From 2006-03-01 11:49:14 PST -------
There's a good discussion of defer here:
http://www.davidflanagan.com/blog/2006_01.html
------- Comment #5 From 2006-03-08 20:28:47 PST -------
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?
------- Comment #6 From 2006-03-08 22:22:34 PST -------
Created an attachment (id=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. 
------- Comment #7 From 2006-03-09 00:42:58 PST -------
(From update of attachment 6950 [details])
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.
------- Comment #8 From 2006-03-09 03:13:16 PST -------
(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 :)
------- Comment #9 From 2006-03-09 21:54:25 PST -------
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 :-/
------- Comment #10 From 2007-08-20 07:37:06 PST -------
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.
------- Comment #11 From 2007-08-20 07:51:15 PST -------
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.
> 
------- Comment #12 From 2007-09-30 03:14:16 PST -------
I'm working on cleaning up this patch.
------- Comment #13 From 2007-09-30 03:22:58 PST -------
Created an attachment (id=16468) [details]
Updated patch
------- Comment #14 From 2007-09-30 03:34:19 PST -------
(From update of attachment 16468 [details])
DOMContentLoaded should probably be a generic event, not a MutationEvent.
------- Comment #15 From 2007-09-30 03:38:17 PST -------
Created an attachment (id=16469) [details]
Updated patch using Event and with faster layout test
------- Comment #16 From 2007-09-30 03:41:41 PST -------
(From update of attachment 16469 [details])
r=me for feature-branch
------- Comment #17 From 2007-09-30 11:09:39 PST -------
This is a GIT diff, someone with GIT (likely bdash) will need to land it on fb.
------- Comment #18 From 2007-09-30 14:58:30 PST -------
Eric, svn-apply handles git diffs just fine.
------- Comment #19 From 2007-09-30 15:29:28 PST -------
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 :)
------- Comment #20 From 2007-10-07 02:08:32 PST -------
(From update of attachment 16469 [details])
Marking this patch as obsolete to remove it from the review queue.  (Since it's obsoleted by a patch on bdash's HD.)
------- Comment #21 From 2007-10-07 02:09:26 PST -------
(From update of attachment 16469 [details])
Bah, commit queue.  And that didn't do it.  Clearing flag.
------- Comment #22 From 2007-10-07 02:10:08 PST -------
(From update of attachment 16469 [details])
Also, (somewhat unrelated) I've heard rumors that "trunk" will be "feature-branch" soon anyway.
------- Comment #23 From 2007-10-07 07:47:28 PST -------
Landed in r26101.