Skip to main content

Bug Tracker

Side navigation

#11082 closed bug (wontfix)

Opened December 20, 2011 11:57PM UTC

Closed June 26, 2012 03:23AM UTC object now incorrect/incomplete until jQuery.ready fires

Reported by: Owned by:
Priority: low Milestone: None
Component: support Version: 1.7.1
Keywords: Cc:
Blocked by: Blocking:


Two recent changes (links below) mean that the jQuery support object is now incorrect/incomplete until jQuery.ready fires. This means jQuery functions incorrectly before this point. The behaviour change is a regression: 1.7.0 doesn't do this; 1.7.1 does. Test case is below.


Various tests that probe the browser environment and update accordingly are now being run inside a function passed to jQuery.ready.

Search for "jQuery(function() {".


A race condition now exists for client code that loads jquery and then uses it immediately, without explicitly waiting for jQuery.ready to fire. If jQuery.ready/browser-probes run first, the client code sees the complete/correct object. If the client code runs first, it sees the incomplete/correct version. This means that jQuery functions incorrectly at this point.

I've seen this problem as I'm loading jQuery into an already loaded page (using a bookmarklet), and then calling jQuery immediately. My client code isn't inside its own jQuery.ready, as I've seen problems in the past with the "ready" event not firing on an already loaded page.


I "fixed" the problem on Mac Firefox 8.0.1 by making all the browser probes for run inline, rather than at jQuery.ready. I just commented out the two uses of "jQuery(function() {". However, this doesn't seem like a long-term fix.

Ideally, (and jQuery as a whole) should be fully initialized by the time jQuery loads. So all setup must run within the jquery load thread, not triggered by a later event. In the case of the browser probes for

  • If the probes need a fully loaded DOM, is there some way of detecting this inline, rather than needing to wait for the jQuery.ready event to fire?
  • Or could a function passed to jQuery.ready be run inline immediately, if the DOM is already loaded?

Test case

Copy html code below into test file, then load and view console. Output shows support object is incorrect before jQuery.ready:

$.support.reliableHiddenOffsets before jQuery.ready: undefined
$.support.reliableHiddenOffsets after jQuery.ready: true
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
    <script type="text/javascript" src=""></script>
    <script type="text/javascript">
        console.log("$.support.reliableHiddenOffsets before jQuery.ready: " + $.support.reliableHiddenOffsets);
        $(function() {
            console.log("$.support.reliableHiddenOffsets after jQuery.ready: " + $.support.reliableHiddenOffsets);

To see correct 1.7.0 behaviour, just load jquery-1.7.0.js instead. Output should be:

$.support.reliableHiddenOffsets before jQuery.ready: true
$.support.reliableHiddenOffsets after jQuery.ready: true

Tested on Mac Firefox 8.0.1 and Safari 5.1.2

Attachments (0)
Change History (3)

Changed December 21, 2011 12:10AM UTC by dmethvin comment:1

component: unfiledsupport
priority: undecidedlow
status: newopen

Sorry, I agree with your analysis but this is something we're more likely to document than change.

Our experience is showing that page load is a very inopportune time to do many of these feature detects. First there is the performance issue; if all the tests have to be done before document ready then we are holding up the page for tests that may not be needed until much later. Then there is the problem that some browsers (particularly old ones) seem to be in a relatively unstable state until the page has fully and completely loaded; feature tests sometimes stress them out.

My preferred solution would be to deprecate as an external interface. We tried to share these feature detects when we could, but they become a liability when others depend on them and we can no longer deliver them reliably or on time. In cases where we no longer need those feature detects due to code rewrites we are technically unable to remove them because it's an external interface.

Changed December 21, 2011 03:29AM UTC by comment:2

Replying to [comment:1 dmethvin]:

Thanks for the quick response. Three points:

Would you be willing to fix this bug for the case when jQuery is being loaded into already loaded page? Stability shouldn't be an issue in this case, as the whole DOM tree is already there. Rough sketch:

  • When doing feature detects that require a full DOM tree, test if the DOM tree is loaded, maybe using the check logic that currently fires the jQuery.ready event.
  • If the DOM tree is loaded, do feature detects inline, else postpone to a jQuery.ready function

I'd very much appreciate this, as this the case I specifically care about.

'''This bug isn't really connected to being externally accessible.''' I tracked this bug down when investigating a huge slowdown in':visible') performance. The root cause was that the underlying logic has a fast way of determining element visibility, if $.support.reliableHiddenOffsets is true. Since the variable now returns undefined, the visibility logic falls back to using the slow alternative.

Improving performance is a laudable goal, but being correct is also important :-) Improving jquery "boot" time is a great idea; doing this by putting off non-essential feature detects seems a good way of doing this. However, this current approach of postponing feature detects until jQuery.ready fires has downsides:

  • jQuery interface functions that are internally dependent on a correct object can now behave slowly, or possibly incorrectly, as with':visible')
  • jQuery usage will now become more complex, and possibly confusing. Users will need to be told (and remember) that jQuery will only behave as expected once jQuery.ready has fired.

I imagine that the ideal solution is some form of just-in-time feature detection, triggered by calling an interface function that uses a particular variable. So, the first call to':visible') triggers a feature detect to set $.support.reliableHiddenOffsets.

Changed June 26, 2012 03:23AM UTC by dmethvin comment:3

resolution: → wontfix
status: openclosed

We'll track this in #10814, and #11766 moved jQuery.browser to an unstable list with the idea that we may change it without deprecation notices.