Skip to main content

Bug Tracker

Side navigation

#10067 closed bug (notabug)

Opened August 17, 2011 12:04AM UTC

Closed September 17, 2012 04:49PM UTC

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

Reported by: skaurus Owned by: mikesherov
Priority: low Milestone:
Component: event Version: 1.6.2
Keywords: 1.8-discuss Cc:
Blocked by: Blocking:
Description

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)

Attachments (0)
Change History (34)

Changed August 17, 2011 02:41AM UTC by rwaldron comment:1

component: unfiledevent
milestone: None1.6.3
priority: undecidedlow
resolution: → wontfix
status: newclosed

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.

Changed August 17, 2011 06:08AM UTC by skaurus <skaurus@gmail.com> comment:2

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/

Changed August 17, 2011 07:59AM UTC by skaurus <skaurus@gmail.com> comment:3

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'

Changed August 17, 2011 01:14PM UTC by rwaldron comment:4

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

Changed August 17, 2011 02:57PM UTC by skaurus <skaurus@gmail.com> comment:5

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

Lot of code possibky would be

|| document.readyState === "interactive"
.

Changed August 17, 2011 03:02PM UTC by skaurus <skaurus@gmail.com> comment:6

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!

Changed August 17, 2011 04:58PM UTC by rwaldron comment:7

resolution: wontfix
status: closedreopened

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

Changed August 17, 2011 05:02PM UTC by rwaldron comment:8

Changed August 18, 2011 03:58AM UTC by skaurus <skaurus@gmail.com> comment:9

Thank you :)

Is this really low priority though?

Changed August 25, 2011 06:43PM UTC by dmethvin comment:10

milestone: 1.6.31.7
status: reopenedopen

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

Changed September 02, 2011 07:43AM UTC by skaurus@gmail.com comment:11

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

Changed September 02, 2011 03:40PM UTC by rwaldron comment:12

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

Changed September 10, 2011 10:19AM UTC by eduardocereto comment:13

Would this be enough to solve the issue?

from this:

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

to this:

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

Changed September 25, 2011 08:49AM UTC by skaurus@gmail.com comment:14

I believe it would.

Now I use

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

after loading my scripts, and it works perfectly.

Changed October 25, 2011 07:51AM UTC by janne.aukia@thinglink.com comment:15

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.

Changed November 05, 2011 04:37AM UTC by mikesherov comment:16

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.

Changed November 05, 2011 02:02PM UTC by rwaldron comment:17

keywords: → 1.8-discuss
owner: → mikesherov
status: openassigned

Changed November 06, 2011 08:15PM UTC by mikesherov comment:18

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

Changed November 11, 2011 01:56PM UTC by dmethvin comment:19

milestone: 1.71.8

Changed December 13, 2011 01:26PM UTC by mikesherov comment:20

description: 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)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)

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

Changed December 13, 2011 04:06PM UTC by jaubourg comment:21

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

Changed December 13, 2011 05:17PM UTC by jzaefferer comment:22

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

Changed December 13, 2011 06:38PM UTC by dmethvin comment:23

description: 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)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)

+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?

Changed December 14, 2011 04:05PM UTC by timmywil comment:24

description: 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)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)

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

Changed December 19, 2011 05:25PM UTC by rwaldron comment:25

description: 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)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)

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

Changed April 23, 2012 08:02PM UTC by dmethvin comment:26

resolution: → fixed
status: assignedclosed

Changed May 16, 2012 06:04PM UTC by Mike Sherov comment:27

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

Changed August 24, 2012 01:15AM UTC by dmethvin comment:28

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

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

Changed August 24, 2012 01:37AM UTC by mikesherov comment:29

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.

Changed August 28, 2012 09:08PM UTC by gleidsondg@gmail.com comment:30

ON IE 9.0.8 with jquery 1.8 ready state never arrives

Changed September 17, 2012 04:20PM UTC by smith comment:31

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

Changed September 17, 2012 04:42PM UTC by mikesherov comment:32

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.

Changed September 17, 2012 04:49PM UTC by dmethvin comment:33

milestone: 1.8
resolution: fixed
status: closedreopened

Changed September 17, 2012 04:49PM UTC by dmethvin comment:34

resolution: → notabug
status: reopenedclosed