Skip to content

Commit

Permalink
Delay the result of the readyState check to give scripts the opportun…
Browse files Browse the repository at this point in the history 
…ity to delay ready, as described by @jrburke in 747ba7d.
  • Loading branch information
@jeresig
jeresig committed Sep 23, 2010
1 parent 2f60335 commit e270d80
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion src/core.js
View file
Expand Up @@ -429,7 +429,8 @@ jQuery.extend({
// Catch cases where $(document).ready() is called after the // Catch cases where $(document).ready() is called after the
// browser event has already occurred. // browser event has already occurred.
if ( document.readyState === "complete" ) { if ( document.readyState === "complete" ) {
return jQuery.ready(); // Handle it asynchronously to allow scripts the opportunity to delay ready
return setTimeout( jQuery.ready, 13 );

This comment has been minimized.

Sign in to view

Copy link
@davidmurdoch

davidmurdoch Sep 24, 2010

Why 13ms? From @jrburke's comment it seems that jQuery.ready just needs to be pushed to the end of the call stack; the delay doesn't matter.

         /* jquery.js */
        if ( document.readyState === "complete" ) {
            // push jQuery.ready to the end of the queue (and do it as quickly as the browser will let us)
            return setTimeout( jQuery.ready, 1 );
        }

        /* scriptLoader.js */
        // window.onload to make sure document.readyState === "complete"
        window.onload = function () {
            // async script loading script...
            (function ( d, t ) {
                var s = d.createElement( t );
                s.async = true;
                s.onload = function () {
                    // I am executed BEFORE setTimeout( jQuery.ready, 1 )!
                   ++jQuery.readyState;
                };
                s.src = "js/jquery.js";
                ( t = d.getElementsByTagName(t)[0] ).parentNode.insertBefore( s, t );
            })( document,  "script" );
        };

From what I've read, Chrome can execute an interval/timeout as quickly as 1ms, Firefox at 10ms or ~15ms, and IE at 15ms (src: http://code.google.com/p/chromium/issues/detail?id=888#c4). In this case, where we don't care about UI responsiveness, I think a 1ms or 0 ms interval is appropriate.

This comment has been minimized.

Sign in to view

Copy link
@jeresig

jeresig Sep 24, 2010

Author Member

Traditionally we like to set a standard threshold for our timers across jQuery - using a consistent rate that won't peg the browser. We picked 13ms as it was roughly the rate at which most timers fire at - thus not overwhelming a browser (see the code in effects.js). I tend to worry about causing different effects across browsers. Dropping the number to 1 will certainly have a different effect in Chrome from IE or FIrefox and I worry that it might cause additional issues. Now it's probably less of an issue with these one-off calls for ready so I've bumped them down a220c81. I plan on making the 13ms effects timer configurable in a follow-up commit so that users can adjust it as they see fit.
} }


// Mozilla, Opera and webkit nightlies currently support this event // Mozilla, Opera and webkit nightlies currently support this event
Expand Down

0 comments on commit e270d80

Please sign in to comment.