Thank you for addressing the ticket! This approach covers most cases, but I believe it may fire the ready callbacks before all scripts are loaded in the following case:
A script loader is used to load jQuery via async script elements dynamically added to the DOM. The script loader knows to increment jQuery.readyWait after jQuery loads but needs to do that work in the script onload event for the script element that loads jQuery.
Page is loaded without jQuery and DOMContentedLoaded fires. Later the page loads jQuery, or jQuery is loaded via an async script tag, but DOMContentLoaded fires before the jQuery script is executed.
At this point the script containing jQuery is executed. The script that contains jQuery has been optimized to include other jQuery plugins, that register ready callbacks with jQuery. There are other scripts loading on the page via other script tags, so the script loader does not consider that the page is really "ready" yet.
jQuery executes, and will see document.readyState === "complete" and since the script is still executing, the script loader will not have had a chance to increment readyWait, so the ready callbacks will fire, even though there are other scripts being loaded.
One solution may be to use a setTimeout for the jQuery.ready() call that is done around line 431 in core.js related to the document.readyState === "complete" that is long enough that it allows the script onload event handler to fire before the setTimeout callback. The script loader would use the script onload event to increment jQuery.readyWait. This is complicated a bit by IE 6-8 that can evaluate a few scripts in a row before the script onload callbacks fire, so I am not sure if the setTimeout could get in the event queue before the script onload, but I expect that chances of that happening will be incredibly small.
Another option is what was illustrated in the attachment to #6781, where instead of using a readyWait property on the jQuery object, use a property on the DOM that holds the wait count. This approach allows the script loader to increment that value before jQuery is loaded. jQuery could then watch for changes to that property to know when to trigger jQuery.ready itself. However, if the code to set up the watch seemed like too much overhead, just coordinating on the DOM property name and asking script loaders to call jQuery.ready directly would still work. The down side is a "global" on the document, but I think this is one case where it makes sense, and it allows other toolkits to leverage the same feature when working with script loaders that only consider the page "ready" when all outstanding scripts have been loaded.
I went with the first solution, I think it's preferred - I'm very much against having some sort of global (even if it's on the document). I landed it in e270d80. Thanks for the detailed description of this issue, though!
I just noticed http://dev.jquery.com/ticket/1124 which was pushed to 1.5; it proposes to extend .ready() for frames. If that is landed in 1.5 we'll need to make the readyWait counter specific to a document.
I had forgotten about that patch - although I don't think that it'll affect what's happening here. The readyWait property is very specific to just delaying the single global ready event - ready for individual frames is fine and doesn't need this functionality (jQuery is already loaded at this point and can delay execution of the even in any way they choose).
This comment has been minimized.
jrburke repliedSep 23, 2010
Thank you for addressing the ticket! This approach covers most cases, but I believe it may fire the ready callbacks before all scripts are loaded in the following case:
One solution may be to use a setTimeout for the jQuery.ready() call that is done around line 431 in core.js related to the document.readyState === "complete" that is long enough that it allows the script onload event handler to fire before the setTimeout callback. The script loader would use the script onload event to increment jQuery.readyWait. This is complicated a bit by IE 6-8 that can evaluate a few scripts in a row before the script onload callbacks fire, so I am not sure if the setTimeout could get in the event queue before the script onload, but I expect that chances of that happening will be incredibly small.
Another option is what was illustrated in the attachment to #6781, where instead of using a readyWait property on the jQuery object, use a property on the DOM that holds the wait count. This approach allows the script loader to increment that value before jQuery is loaded. jQuery could then watch for changes to that property to know when to trigger jQuery.ready itself. However, if the code to set up the watch seemed like too much overhead, just coordinating on the DOM property name and asking script loaders to call jQuery.ready directly would still work. The down side is a "global" on the document, but I think this is one case where it makes sense, and it allows other toolkits to leverage the same feature when working with script loaders that only consider the page "ready" when all outstanding scripts have been loaded.
This comment has been minimized.
jeresig repliedSep 23, 2010
I went with the first solution, I think it's preferred - I'm very much against having some sort of global (even if it's on the document). I landed it in e270d80. Thanks for the detailed description of this issue, though!
This comment has been minimized.
jrburke repliedSep 23, 2010
Awesome, thanks!
This comment has been minimized.
dmethvin repliedSep 28, 2010
I just noticed http://dev.jquery.com/ticket/1124 which was pushed to 1.5; it proposes to extend .ready() for frames. If that is landed in 1.5 we'll need to make the readyWait counter specific to a document.
This comment has been minimized.
jeresig repliedSep 28, 2010
I had forgotten about that patch - although I don't think that it'll affect what's happening here. The readyWait property is very specific to just delaying the single global ready event - ready for individual frames is fine and doesn't need this functionality (jQuery is already loaded at this point and can delay execution of the even in any way they choose).