Firing $.ready on document.readyState === 'interactive' too

[skaurus]

Sorry if dup.

So; imagine situation: FF5, page with ever loading iframe (any other resourse will do I think), jQuery executed after DOMContentLoaded fired (asynchronous loading). On $.bindReady stage document.readyState consistently (a lot of Ctrl+F5) equals to 'interactive', so $.ready wont fire ever, right?

It makes panda sooo sad)

[Rick Waldron]

jQuery provides a solid, consistent document ready handling system that has been battle tested for the last 5 years on upwards of 24 million websites.

[skaurus <skaurus@…>]

WTF is that?

I provided a number of steps that leads to bug clearly, that's easy to see just looking to $.bindReady source.

The only thing that needs proving is that FF5 can have document.readyState === 'interactive' after DOMContentLoaded fired.

But this is 1) W3C compliant - ​http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html says 'document.readyState Returns "loading" while the Document is loading, "interactive" once it is finished parsing but still loading sub-resources, and "complete" once it has loaded.' Looks like FF5 adopted this; 2) easily proved.

But instead of investigation or providing technical reasons why current behaviour is right or why it can't be reliably fixed you just give me some marketing. No thanks.

There, have a test case: ​http://jsfiddle.net/skaurus/xGtUf/1/

[skaurus <skaurus@…>]

Also Yansky from this stackoverflow question ​http://stackoverflow.com/questions/3665561/document-readystate-of-interactive-vs-ondomcontentloaded states that he was given information by one of mozilla developers that 'DOMContentLoaded event equates to the document.interactive readystate'

[Rick Waldron]

So, what benefit would jQuery get by adding a lot of extra code to handle something that is "equivalent" to what it already does?

[skaurus <skaurus@…>]

Don't you see - in testcase jQuery.ready never ever fire? Although DOMContentLoaded did?

Lot of code possibky would be || document.readyState === "interactive".

[skaurus <skaurus@…>]

The only possible way to jQuery to discover that DOMContentLoaded already fired, is check for document.readyState === "complete", line 454.

Possibly before FF5 after DOMContentLoaded it indeed always was equal to complete.

But now after DOMContentLoaded and before onload it's interactive, so check for "did DOMContentLoaded already fired?" on line 454 fails, then jQuery setups listeners for DOMContentLoaded, which will never fire, because it's already fired!

[Rick Waldron]

My apologies, my initial resolution was short sighted. Thanks for your patience

[Rick Waldron]

More info... ​http://jsfiddle.net/rwaldron/cUqWc/

[skaurus <skaurus@…>]

Thank you :)

Is this really low priority though?

[dmethvin]

I am not clear on the case where this would happen. The test case shows something uncommon, loading jQuery after the doc is ready.

[skaurus@…]

It would happen when jQuery loaded asynchronously, it's a rarity, but it's good practice. Async js loading generaly advised for higher perfomance.

[Rick Waldron]

We've made concessions for RequireJS's needs this has yet to be an issue

[eduardocereto]

Would this be enough to solve the issue?

from this:

if ( document.readyState === "complete" ) {

to this:

if ( /complete|interactive/.test(document.readyState) ) {

[skaurus@…]

I believe it would.

Now I use

if (document.readyState === "interactive") jQuery.ready();

after loading my scripts, and it works perfectly.

[janne.aukia@…]

This problem shows in practice on Webkit (Safari/Chrome) when DOMContentLoaded has fired before the jQuery.ready() is set up. This makes Webkit wait until window.load before $(document).ready fires.

In practice, in our application, this made $(document).ready fire 5 seconds slower on Safari/Chrome compared to Firefox! So for some sites and apps, this bug can cause serious slowdown while being difficult to debug.

[mikesherov]

Correct me if I'm wrong, but simplest patch seems to be:

document.readystate === "complete"

To

document.readystate !== "loading"

Heck, we even save a byte ;). Writing the unit test shouldnt be terrible either.

[mikesherov]

ok, so writing the unit test IS terrible. But I making solid progress... early results seem to indicate that the change is fine.

[mikesherov]

-1, I've been working on this ticket, and tested this in the general case, and it seems to work. It's also one of the simplest changes to make, while very difficult to test. However, I don't know if this would break an expectation that when $.ready fired it meant you could interact with the content of IFRAMEs on the page. Also, it just seems like this is a bit too much of an edge case to change the current behavior.

[jaubourg]

+1, We just need to document that the dom of iframes is not guaranteed to be ready in that instance.

[jzaefferer]

+0, Try to figure if its a bug and handle as such. Too complicated for a vote really.

[dmethvin]

+0, Changes in .ready() make me worried when we can't test them easily. So what is the specific benefit to this, and how commonlly is it needed?

[Timmy Willison]

+1, I'm ok with adding interactive if it does not create bugs

[Rick Waldron]

+1, Despite my previous opposition, I'd be interested in giving this a go

[dmethvin]

​https://github.com/jquery/jquery/pull/736

[Mike Sherov]

Fix #10067. Create jQuery.quickReady; closes gh-736.

Allows us to get to the ready state sooner by not waiting for iframes to load. If that causes backcompat pain, use jQuery.quickReady = false as prescribed by your developer.

Changeset: 54fab3174c7844959b374e98b453c048b60de0d0

[dmethvin]

We tried, it didn't work. We learned a lot. Like, never listen to skaurus.

​https://github.com/jquery/jquery/pull/907

[mikesherov]

Well, it doesn't work in IE9/IE10, and Android 2.1. Perhaps at a future date, we may be intrepid enough to try this again? I'm a glutton for punishment.

[gleidsondg@…]

ON IE 9.0.8 with jquery 1.8 ready state never arrives

[smith]

Does this need to be reopened? #12282 had a regression that reverted the changes made above.

[mikesherov]

It's not going to get fixed at least until IE9.0 and IE10 die. So we'll reopen this in 2020 when a fix can be reasonably applied.