#4087 - insertAfter, insertBefore, etc do not work when destination is original element

[PaulBRamos]

No description provided.

[gibson042]

I think this entire special-case block and corresponding expense of .index can be eliminated if the jQuery( this ).remove() on L296 moves after the .before/.append. Did you try anything like that?

[PaulBRamos]

I didn't, but I can definitely give it a shot.

[markelog]

jQuery.remove() not only remove node from DOM, but also remove all data from the element,
so with this change, if we have, for example, events attached to node that replaces itself, all events from that node will be lost.

@PaulBRamos how you feel about this suggestion?

[gibson042]

This approach has promise, but also a fair amount of risk and potential pitfalls. I have to wonder about alternatives like creating temporary proxy nodes (that wouldn't get detached when their analogs were pulled into a fragment), or—potentially more performant—a callback for domManip/buildFragment that lets the caller see the set of preexisting nodes about to be swept into a fragment and perform some prep work before that happens. In this case, the callback would look something like:

function( fragmentChildren ) {
    self.each(function() {
        jQuery._data( this, "sub", isDisconnected( this ) || !jQuery.inArray( this, fragmentChildren ) ?
            this :
            this.parentNode.insertBefore( this.ownerDocument.createTextNode(""), this )
        );
    });
}

[PaulBRamos]

I definitely see your concerns. I had considered the method you mentioned above, but went with this solution to minimize the footprint of the change. I'll explore this alternative if you think it's more promising.

[dmethvin]

@PaulBRamos Thanks for looking at this ticket! As you can tell it's been sitting around for a while but your solution looks like it could be pretty elegant. It's definitely worth doing some experiments to see if there is a better/smaller way.

[gibson042]

@PaulBRamos I'd certainly like to see how it goes. Now that I've pulled the rug out from under these changes with 22f58bd anyway, how about giving it a shot with a new branch from master?

[PaulBRamos]

@gibson042 That's exactly what I'm doing. :)

[dmethvin]

Where does this stand now? It seemed like the technique was showing some promise.

[PaulBRamos]

I'm about to do a pull request for a newer version of this fix.

[PaulBRamos]

new pull request for this issue: #1047