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 comment:1
component: | unfiled → event |
---|---|
milestone: | None → 1.6.3 |
priority: | undecided → low |
resolution: | → wontfix |
status: | new → closed |
Changed August 17, 2011 06:08AM UTC by 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 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 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 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 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
onloadit'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 comment:7
resolution: | wontfix |
---|---|
status: | closed → reopened |
My apologies, my initial resolution was short sighted. Thanks for your patience
Changed August 17, 2011 05:02PM UTC by comment:8
More info... http://jsfiddle.net/rwaldron/cUqWc/
Changed August 18, 2011 03:58AM UTC by comment:9
Thank you :)
Is this really low priority though?
Changed August 25, 2011 06:43PM UTC by comment:10
milestone: | 1.6.3 → 1.7 |
---|---|
status: | reopened → open |
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 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 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 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 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 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 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 comment:17
keywords: | → 1.8-discuss |
---|---|
owner: | → mikesherov |
status: | open → assigned |
Changed November 06, 2011 08:15PM UTC by 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 comment:19
milestone: | 1.7 → 1.8 |
---|
Changed December 13, 2011 01:26PM UTC by 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 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 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 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 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 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 comment:26
resolution: | → fixed |
---|---|
status: | assigned → closed |
Changed May 16, 2012 06:04PM UTC by 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 comment:28
We tried, it didn't work. We learned a lot. Like, never listen to skaurus.
Changed August 24, 2012 01:37AM UTC by 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 comment:30
ON IE 9.0.8 with jquery 1.8 ready state never arrives
Changed September 17, 2012 04:20PM UTC by 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 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 comment:33
milestone: | 1.8 |
---|---|
resolution: | fixed |
status: | closed → reopened |
Changed September 17, 2012 04:49PM UTC by comment:34
resolution: | → notabug |
---|---|
status: | reopened → closed |
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.