At the moment there are two schools of thought on how this bug should be handled. We can either close as invalid given that the use-case is a paradox which would likely not affect a huge number of users, or we can fix.

I personally feel that this in incorrect usage and should be closed, however there may be valid use-cases which I haven't thought of as yet.

Bare in mind: should we decide to fix this, all manipulation methods may need to be updated to check if they themselves are the target of the manipulation.

Other notes: ajpiano discovered that this works in 1.2.6 but breaks in 1.3. Opening the floor to other thoughts on this.

While this test case does seem a bit curious, we've concluded there are vaguely viable reasons why a user might happen to write something like this, and the behaviour is indeed confounding. Also, interestingly, this code works in jQuery 1.2.6, but breaks in jQuery 1.3 and above. It also breaks with .after();

PS. Thanks addy for making this comment irrelevant while I was in the middle of typing it.

I consider this entirely plausible as well -- while the use case might not be desirable, it doesn't feel at all unreasonable, and the last thing you want happening in this case is for your element to disappear entirely.

It may go without saying, but so far this seems to happen with manipulation methods across the board in 1.4.4. Here's another possibly more plausible test case:

http://jsfiddle.net/ctej7/2/

Our further discussions on this seem to indicate that there is a level of validity to it getting fixed. Our group consensus is that at minimum, elements should not simply 'disappear' as per what was experienced with the original ticket.

Without digging too deeply into the code, we believe that the reason this issue is being caused is because we're internally pulling the element in a fragment and inserting obviously fails since it isn't there anymore and no longer has a parent.

Our current concern is how costly it would be to do the required check across all manipulation methods - we don't *think* it would be too expensive, however we could be wrong. CC'ing John for his input too.

I personally feel that this in incorrect usage and should be closed, however there may be valid use-cases which I haven't thought of as yet.

I catch this bug in real code. Some works about dynamic reordering of elements.

Of course i solve this issue easily by additional checks in my algorithm, but before i assumes, that any DOM manipulations have behavior as described in W3C DOM Level 1/2/3 and i thinking in same terms.

Thanks!

Duplicate of #4087.