.live() delegation fails in second handler if first handler modify the DOM

[iraebrasil]

From the jQuery Development list: I'm using 1.3b2 (6070) and found the following behavior.

• using 2 .live() handlers for same link.
• 1st handler always fire and modify the link with .html(string)
• 2nd handler fire once, them stops firing.

I've made a test case: ​http://irae.pro.br/jquerytests/live.html.html

The weird thing is that after the manipulation, if you stop modifying the DOM (use toggle link in test case), both handlers fire again.

I dug into jQuery source but was unable to solve the problem myself to present a patch. But I found out that if I use .wrapInner() instead of .html() everything works fine. To me it seems that .closest() used in liveHandler can't match the element for delegation during domManip for some reason, but this was as far as I could get.

From: John Resig

Here is what I think is happening:

First click: Since there's only a text node inside of the link both callbacks work as expected - the target of the event is the anchor element. The one handler ends up modifying the contents with .html().

Second click: The first handler is run - but the target is the span, this time. You end up deleting the span while the event is still happening - stranding all the other events (they were targeted on an element that no longer exists).

For example, if you used .text("Click me") instead of the html business then this would've worked.

I don't really see a clear way to make this "just work". The target of the event was nuked while the event was still happening - we're kind of up the creek without a paddle on this one.

I'm open to thoughts, but I don't see a clear way to resolve this - at least not before the final 1.3 release.

Could you open a bug on this, at least? It'll be good to remember this issue.

[iraebrasil]

Test case for loosing the target for delegation but not a test unit

[iraebrasil]

patch to make a queue before firing every liveHandler solves #3820

[iraebrasil]

Unit test proposal for this issue that the patch passes and without the path, don't

[john]

Fixed in SVN rev [6079] - thanks for the patches! Had to make a couple tweaks but they were good, thanks.