$script.domReady doesn't work correctly in IE, Chrome, Opera, & Firefox.

[jdalton]

Your $script.domReady() solution fails to work correctly in versions of IE, Chrome, Opera, & Firefox (http://jsbin.com/uxure5) and instead produces results similar to window.onload.

[fat]

Thanks for reporting, we started playing around with some different solutions today.

[gryzzly]

also 1.2 doesn't actually attach private domReady to the $script, like it did in 1.1.

[lmartins]

Not sure if it is related to this ticket, in my case when i try to use $script.domReady() i get an JS error: $script.domReady is not a function

This is with the latest version pulled today from github.

[gryzzly]

@lmartins - downgrade to 1.1 - you'll have domReady working, or don't depend on $script.domReady, use $(function() {}) if you use jQuery or maybe some other domready event, I haven't really had problem with using that, actually.

[ded]

fixed. 167a541

[ded]

just recalling this - it might fail if a document "incomplete" occurs

[jdalton]

just recalling this - it might fail if a document "incomplete" occurs

There is no incomplete state so that shouldn't be an issue (source).

There is still a problem with the dom-load detection.
IE8 starts out at the readyState of interactive, IE6/7 at loading, and at some point in the interactive state become dom-loaded. Just checking for interactive can lead to firing too soon and in IE6/7 may lead to an operation aborted error.

Here is a test to confirm a JS error in IE6/7/8 when attempting to use $script.domReady: http://jsbin.com/akeke3

[ded]

cool. I couldn't find references to incomplete (it's only for XHR apparently). I'll bootup IE and have a play. I'm a bit less worried about iframes (and the doScroll hacks). getting this base will cover what we need.

[jdalton]

The doScroll technique is one of the only ways to detect when dom is loaded within the interactive state. The doScroll technique works on primary documents only,not iframes, and so a fallback to readyState complete is also used so that it at least fires juuuust before window.onload.

[ded]

cool. not much trickiness, but it now passes in IE7+ (quirks & standards) — i'm afraid i don't have access to IE6 atm. I imagine it passes. thanks again.
529f06f

[jdalton]

Opera may also contain "msi" in its UA string. There is no need for sniffing, at least replace it with a simple inference 'doScroll' in div.

You should avoid doScroll on an element in the document because it may actually scroll. Instead perform the check on a dummy div. A small note, top is not a valid argument to pass to doScroll.

An onreadystatechange event handler is also needed as a fallback for iframed documents.

[jdalton]

In iframes doScroll won't throw an error so the fn() will be called too soon. MooTools has a recent commit you might get inspired from.

[ded]

patched.
84321a1
just out of curiosity, do you even ever plan on using this script? you've found some interesting gotchas but was curious if there was anything you were getting out of it.

[jdalton]

Sorry, I know you want the bug squashed, but it's still not working in IE iframes (window onload is firing before dom-load): http://jsbin.com/abise4

[ded]

i tested this already. it works for me in IE7 quirks. maybe i'm missing something

[ded]

that's weird. that jsbin example doesn't even put in window onload.

[ded]

this is what i see on jsbin.

[ded]

^ turns out IE (on Windows7) blocks bad mimetypes from linking to the raw github sources.

[jdalton]

i tested this already. it works for me in IE7 quirks. maybe i'm missing something

You're missing a ton of history behind the current dom-load solutions.

The window.top reference you have can cause a ~9 second hang in IE iframes. http://bugs.jquery.com/ticket/4787.

As mentioned earlier you'll also need to use a document onreadystatechange event handler as backup.
Review the MooTools & jQuery code. They've had working solutions for ~3 yrs now. It will help you avoid a lot of the issues that keep cropping up.

Things to note:

• They use doScroll without an argument or use a valid documented argument ("top" isn't a valid argument)
• +1 for Moo as it calls doScroll on an element detached from the document (not the documentElement)
• They avoid referencing window.top
• They have a readystatechange fallback.

[ded]

i did the onreadystatechange while you were responding. everything appears to be working now.

[ded]

i'm not accessing any properties on top. it's only a comparison check. it's also not hanging for me. http://jsbin.com/akige5/5

[ded]

the detached element is a good idea. just added it in. since everything is working. i'm closing this out now. thanks for the research.

[ded]

for your own sanity as well, it's not causing the x-domain issues you brought up. self != top is just making sure you're in a framed document. however if one attempts to access a property (like top.foo) - then you'll get the security errors.

[jdalton]

Yap, the window.top hang is triggered when combined with window.frameElement. The hang I was seeing was an artifact of the detection. But it seems fixed now so \o/

[ded]

hmmm.... that's no good. can you reproduce? perhaps it was an intermittent upload i was doing...

[jdalton]

Ya could be, I will dig around a bit. On a side note, you should use attachEvent instead of the document.onreadystatechange = ... in case 3rd party scripts are using it. Also you should remove the event handler when dom-loads to avoid the IE6 memory leak.

[ded]

since listening to 'onload' is sometimes causing it to fire after the other onload, i used attachEvent('onreadystatechange', then of course, detach the event when the document is complete. this at the least ensures it fires before someone else's window.onload, and won't collide with someone elses document.onreadystatechange.

[jdalton]

Here is the requested test for the IE6 window.top hang: check here (it's edge-case, but a possible third-party script concern):

[jdalton]

Phew, now that this issue is practically resolved it would rock if the blog post, "Smallest DOMReady code, ever.", would be tweaked so that others don't have to go through all this.

[ded]

i can make a note of it.

[jdalton]

Thanks for adding the note to your blog. I forgot to mention that the doScroll technique is based on the work of @dperini.