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

Closed
jdalton opened this Issue Feb 28, 2011 · 31 comments

Comments

Projects
None yet
5 participants
@jdalton

jdalton commented Feb 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@fat

fat Mar 2, 2011

Collaborator

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

Collaborator

fat commented Mar 2, 2011

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

@gryzzly

This comment has been minimized.

Show comment
Hide comment
@gryzzly

gryzzly Mar 10, 2011

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

gryzzly commented Mar 10, 2011

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

@lmartins

This comment has been minimized.

Show comment
Hide comment
@lmartins

lmartins Mar 16, 2011

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.

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

This comment has been minimized.

Show comment
Hide comment
@gryzzly

gryzzly Mar 16, 2011

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

gryzzly commented Mar 16, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

fixed. 167a541

Owner

ded commented Apr 12, 2011

fixed. 167a541

@ded ded closed this Apr 12, 2011

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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

jdalton commented Apr 12, 2011

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

@jdalton jdalton reopened this Apr 12, 2011

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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.

Owner

ded commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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.

jdalton commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@ded ded closed this Apr 12, 2011

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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 commented Apr 12, 2011

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 jdalton reopened this Apr 12, 2011

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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.

jdalton commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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.

Owner

ded commented Apr 12, 2011

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.

@ded ded closed this Apr 12, 2011

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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

IE8 screenshot

jdalton commented Apr 12, 2011

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

IE8 screenshot

@jdalton jdalton reopened this Apr 12, 2011

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

this is what i see on jsbin.

img

Owner

ded commented Apr 12, 2011

this is what i see on jsbin.

img

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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.

jdalton commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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.

Owner

ded commented Apr 12, 2011

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 ded closed this Apr 12, 2011

@ded

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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.

Owner

ded commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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/

jdalton commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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

Owner

ded commented Apr 12, 2011

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

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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.

jdalton commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 12, 2011

Owner

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.

Owner

ded commented Apr 12, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 12, 2011

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

jdalton commented Apr 12, 2011

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

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 13, 2011

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.

jdalton commented Apr 13, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ded

ded Apr 13, 2011

Owner

i can make a note of it.

Owner

ded commented Apr 13, 2011

i can make a note of it.

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Apr 13, 2011

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

jdalton commented Apr 13, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment