Permalink
5 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Allow plugins to delay the exeuction of the ready event. Delay the re…
…ady event by calling: jQuery.readyWait++ and force the event to fire by doing: jQuery.ready(true). Fixes #6781.
- Loading branch information
Showing
1 changed file
with
16 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
747ba7d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
747ba7d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
747ba7d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks!
747ba7d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
747ba7d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).