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.
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.
Reassigning to webkit-unassigned, to make sure more people see this.
Discussed this on IRC with ggaren and mjs, and it is a valid request.
There's a good discussion of defer here: http://www.davidflanagan.com/blog/2006_01.html
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?
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.
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.
(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 :)
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 :-/
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.
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. >
I'm working on cleaning up this patch.
Created attachment 16468 [details] Updated patch
Comment on attachment 16468 [details] Updated patch DOMContentLoaded should probably be a generic event, not a MutationEvent.
Created attachment 16469 [details] Updated patch using Event and with faster layout test
Comment on attachment 16469 [details] Updated patch using Event and with faster layout test r=me for feature-branch
This is a GIT diff, someone with GIT (likely bdash) will need to land it on fb.
Eric, svn-apply handles git diffs just fine.
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 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.)
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.
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.
Landed in r26101.