I've just seen in the Chrome debugger that when "ready" is entered the second time (reentered I should say), the "wait" parameter is an Event object. The code seems to expect "wait" to be either boolean "true" or boolean "false", or at least those are the only values it's interested in.

I see the same behavior in Safari/Windows as in Chrome.

If I change line 419 from:

  if ( !jQuery.readyWait || (wait !== true && !jQuery.isReady) ) {

to

  if ( (!jQuery.readyWait || wait !== true) && !jQuery.isReady ) {

then the code works fine (for me). Whether that's semantically what's wanted, I don't know. All I know is that some weird WebKit behavior is causing the "ready" handler to be invoked while a call is pending, so that "if" statement is no longer correctly terminating the call.

It's not clear in my original writeup, but this effect is not noticed all the time. In fact, it's pretty uncommon; when it starts happening, however, it tends to "stick".

Can you test this in 1.4.4rc1? Improvements were made to this code after 1.4.3:

http://code.jquery.com/jquery-1.4.4rc1.js

I'll give it a try, but I don't think that's going to work. The root problem is really the fact that a call to that "ready" function is somehow being triggered while the function is already running, and it's invoked with an Event object as its single parameter. At that point, readyWait has already been decremented to zero (during the execution of the call higher up the stack). Thus, the "wait" parameter is neither "true" nor "false", so that "if" statement that checks to "!jQuery.readyWait" is going to allow control to flow into the loop, and then eventually to set readyList to null.

I wish I knew how it can be the case that the event handler is invoked like that; my understanding of reality is such that I would expect that to be impossible. It occurs to me however that it might be interesting to examine the Event object ...

It still happens with 1.4.4rc1. (Really, I don't see any obvious difference in that particular code.)

The Event object being passed in to the reentrant call to "jQuery.ready" is a "load" event with the document as the target. That is apparently being triggered by that call to "appendChild" inside "clean". At least, that's what the stack trace shows. It's pretty weird.

I can make an attempt to come up with test case, but as I said the site is a secured web app and I don't have an easy way of peeling out just this one page. (It may happen on more of my pages of course, since they all use the same tools, but they'd be no easier to make available.)

Oh also, more on the weirdness: it does not appear to be any sort of race condition. Whatever it is about the DOM that causes the browser to do what it does, it happens whether I let the script just run normally or if I pepper it with breakpoints. It always happens when it's doing exactly the same thing; it's not just any call to the domManip code, it's a specific thing in this page (that's not unusual with my application, but not all pages seem to suffer the same way).

More possibly useless information: I'm pretty sure that whatever WebKit is doing, it did it on my page under 1.4.2 but because that code just relied on "isReady" to avoid reentrance no harm was done. If I fiddle with the 1.4.2 version to detect the situation, I can see it happening. Thus the weird behavior does not seem to be triggered by anything else new going on in 1.4.3.

I can verify this. I'd say this is a high priority to get done before 1.4.4, but any second opinions?

Sounds like #7352 is a duplicate of this - also has a test case. Will be closing this one and moving the discussion over there.

Duplicate of #7352.

I can confirm that my page is appending a frame in a "ready" handler!