Yes, cloning expandos is by the design for oldIE, see #1034 and

In order to fix this minor bug we need to iterate over like 154 (in IE8) properties for every node. Which
is not unplesant to say the least. I suppose best way to do this is bring back use of clear(merge)Attributes methods, otherwise i would ask you to prove that your way is better, since performance here is matters, especially for older browsers.

There is easy and obvious way to fix this, right? Is to expose Sizzle expando like we expose jQuery expando – jQuery.expando and remove that property explicitly, it is not a generic fix yes, but this issue didn't come up for two years and when it did, it was isolated for Sizzle case only, i think this bug is confine enough and we should threat it as such, therefore we shouldn't provide additional complexity, performance and size (Yep, that is only 12 bytes, but you get there only because you optimized support module) issues into this.

I think we should land support module opmization and provide different PR for #15104.

I was hoping the typeof checks would offset performance penalties, but it looks like you're right: http://jsperf.com/jquery-pr-1652

Does anyone else (@dmethvin, @rwaldron, …) want to weigh in on the palatable options?

1. Restore the clearAttributes & mergeAttributes calls removed by Fixes #12956 - Improve cloneFixAttributes function #1034
2. Expose and utilize Sizzle.expando, fixing the case from http://bugs.jquery.com/ticket/15104 but tolerating copied references in other properties

I'm inclined towards 1, but weakly.

It turns out that mergeAttributes copies expandos, making it no help at all. However, iterating over dest.attributes instead of dest does cut the cloning performance hit in half, which still stings but I think can be tolerated: http://jsperf.com/jquery-pr-1652/2

And as a bonus, it comes with a small size reduction:

   raw     gz Compared to 1.x-master @ a9533893b9e5e9a248139f5794c5d6099382cf14
  -146    -16 dist/jquery.js
   -85    -15 dist/jquery.min.js

I'm sorry, i should have been pay more attention to this issue. We were over this again and again, maybe not you, but i have been and i should have been remember this.

For oldIE, this –

div.test = 1;
// and
div.setAttribute( "test", 1 );

is the same thing, for everyones else it is not.

Every other browser will copy content attributes but not element properties. So essentially, this

$( "<div/>" ).attr( "test", 1 ).clone().attr( "test" );

Will have different effect comparing to oldIE with everyone else.

In short: just expose Sizzle expando.

Every [non-oldIE] browser will copy content attributes but not element properties.

Yes.

So essentially, this

$( "<div/>" ).attr( "test", 1 ).clone().attr( "test" );

Will have different effect comparing to oldIE with everyone else.

Huh? Did you mean to use prop instead of attr?

In short: just expose Sizzle expando.

I don't see how that follows. This is an oldIE problem broader than Sizzle, and the fix here is specific to oldIE.

alert( $( "<div/>" ).attr( "test", 1 ).clone().attr( "test" ) );

Execute this code with your changes in Chrome (for example) and oldIE. And do the same with current 1.x-master

I think it would be better than explaining the same thing with words

Ah, the scales have fallen from my eyes. Updates forthcoming, including test suite additions.

Done, except for some support size optimizations that should take place in or after #1664 (use of support.deleteExpando only for the data module and consolidation of manipulation module oldIE attroperties tests—noCloneEvent cum cloneProps and attrProps—into a single support property).

Don't understand why you clinging to this solution so badly:

Execute this code with your changes in Chrome (for example) and oldIE. And do the same with current 1.x-master

div = document.createElement( "div" );
div.setAttribute( "test", 1 );

alert( $( div ).clone().attr( "test" ) );

That's intentional; setAttribute takes two strings: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-F68F082

And we don't make a habit of supporting non-jQuery DOM abuse.

setAttribute takes two strings: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-F68F082

If everything in browser would work according to the spec, that would be great.

And we don't make a habit of supporting non-jQuery DOM abuse.

Not sure if that could be considered as "abuse", my point is you trying to solve very minor issue, while providing new behavior that could bite us in the future.

Why not do the same thing as we did before? I.E. remove Sizzle expando just like we did with jQuery expando? It work perfectly, no one had issues with that and now we introducing some unpredictable code-path with no real reason at all, which would affect people code, even if we considered that as an "abuse" or not, which would give us additional complexity, performance decrease and size increase.

We have fixCloneNodeIssues to fix cloneNode issues, and the fact that non-scalar properties are copied by reference is as much an issue as is script blanking or input/textarea default value dropping.

is as much an issue as is script blanking or input/textarea default value dropping.

It wasn't for as long as jQuery existed, only case that is come up was related to our internal logic, i propose to use simple way first, when (if) someone would face that in real life - only than i would adopt something more.

Whereas those issues -

script blanking or input/textarea default value dropping

Was a real issues from the start

I'll also note that the PR in its current state fixes pollution from multiple instances of Sizzle and/or jQuery¹, which is not otherwise possible.

At any rate, @markelog and I appear to be at an impasse. Would anyone else like to offer an opinion?

¹ Excepting HTML5 elements, upon which the jQuery expando is a string (which is why the dest.removeAttribute( jQuery.expando ) line had to stay).

I suppose "adjudicator" from the team would suffice

None of the choices look that good to me. Just clearing the Sizzle expando for the copy of Sizzle used by this jQuery won't fix any .noConflict() copies and could create latent issues with other expandos. But iterating over the attributes list seems like a bad performance hit to a browser that already is slow.

Given the tradeoffs I guess I'd go with clearing the Sizzle expando; let's see if any of the other potential latent issues are ever reported.

"There is no unsolvable problems only unpleasant solutions"
I suppose this quote is applicable :-(

So we didn't wrap up consensus this week for what we would do here. I'd just propose we clear the Sizzle expando for the current jQuery instance, assuming that will fix most of the cases where this is likely to occur. Thoughts?

Looks like we on agreement and because it one of the last 1.x-master PR's i'm closing it.