id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blocking	blockedby
7344	"New ""readyWait"" logic and webkit don't get along"	Pointy	Pointy	"The 1.4.3 ""jQuery.ready"" code differs from the 1.4.2 code.  In particular, in 1.4.2 the fact that ""jQuery.isReady"" is set to ""true"" before the readyList is acted upon assured that reentering ""jQuery.ready"" would not cause a problem.  In 1.4.3, however, things are different.  There's a counter called ""readyWait"", which provides another way for control flow to get to the point at which the registered ""ready"" handlers are invoked.  For reasons I don't understand, it seems that webkit (Chrome 7.something on Linux, in this case) is triggering a call to ""jQuery.ready"" while the code is in the middle of a pending call.  (The stack trace consistently shows that a call to ""appendChild"" on a document fragment, from inside the ""clean"" routine, is the parent of the call to jQuery.ready, which confuses me.) Maybe that happened in 1.4.2 also, but in that code the call would have had no effect.  Now, however, that nested call to ""ready"" manages to make it to the ready list, resulting in the ready handlers being called again, and (worse) the readyList being set to null. When that call to ""ready"" returns, eventually the initial call will make it back to the loop, and get an exception when it tries to look at the ready list.

I have no idea how to create a test case for this; it's happening to me on a moderately complicated page on a site I can't easily expose.  However, a visual inspection of the new 1.4.3 version of the code should make it pretty clear that it's possible to get to the loop if the code is invoked somehow from inside a handler call.
"	bug	closed	high	1.4.4	event	1.4.3	duplicate	readyWait ready