Fix jQuery #13331: Detached node sorting

[gibson042]

cc @timmywil @dmethvin

I'm not thrilled about +47 bytes to jquery.min.js.gz or about the performance hit, but at least the latter is mostly confined to applicable scenarios. At any rate, I couldn't come up with anything better here... if no one else can either, I guess we should just land this for jQuery 1.9.1.

[dmethvin]

Okay, my head is hurting but I think I see what you're doing. If these APIs actually worked correctly, yeah, it would be faster and smaller. But we'd be out of a, um, hey waitaminit, why are we doing this again?

[gibson042]

why are we doing this again?

I guess because if we don't do it here we'll probably have to do it in jQuery anyway.

[timmywil]

/me cries

[gibson042]

I know, I know... I put this up to solicit other options on the hope that there was a clever solution—in either Sizzle or jQuery—that I missed.

[dmethvin]

Seems like the case that would bother people the most is totally detached elements like the original test case. So would it make sense to make a run through the sortInput and see if nothing is connected, then skip the sort entirely? Could we use parentNode for that? Do we care about mussing up the mixed attached-and-detached case?

[gibson042]

No matter what, it'll probably prove difficult to synchronize such special casing against all supported environments. I certainly wouldn't want to do a contains( document, node ) check on every element before sorting, but a parentNode scan would be a small enough hit.

The problem is that skipping the sort would yield unexpected failures (sometimes introducing duplicates and sometimes having bizarre orderings like A,B,F,P,W,S,T,G,H,I) in response to esoteric circumstances (e.g., .clone or $detached.find( selector ).addBack() or positional selectors).

[timmywil]

@dmethvin : Unfortunately, parentNode isn't usable for this since elements can have detached parents or be on document fragments. contains would have to be called on each element in the array.

[timmywil]

@gibson042 : what about something like slick's createRange usage ==>

if (!a.ownerDocument || !b.ownerDocument) return 0;
var aRange = a.ownerDocument.createRange(), bRange = b.ownerDocument.createRange();
aRange.setStart(a, 0);
aRange.setEnd(a, 0);
bRange.setStart(b, 0);
bRange.setEnd(b, 0);
return aRange.compareBoundaryPoints(Range.START_TO_END, bRange);

[timmywil]

We'd need our preferredDoc check in there of course.

[gibson042]

@timmywil Error: WRONG_DOCUMENT_ERR: DOM Exception 4

[timmywil]

@gibson042 : maybe we could use that error? or avoid it by checking if ownerDocuments are equal and not fragments?

[gibson042]

So what do we return when compareBoundaryPoints throws an exception? It can't be zero, because that's what we're already doing to cause http://bugs.jquery.com/ticket/13331.

[dmethvin]

So we need to figure out some solution for 1.9.1; I'd like to do a release Friday.

[timmywil]

I can help with this tomorrow.

[timmywil]

@gibson042 : yea, that range path doesn't really help us. Here's a commit that's basically the same, but with a support test and always slicing for sortInput. I'm weary of all the top scope vars we have so I say we just slice for sortInput every time. 2fd7ddb843e8a1848b8f286c38a40bd5613ba2eb