Nice detective work! 👍 I think we'll have to land something in 1.9/2.0 since IE9 is not gonna get fixed and I think it's even too late for an IE10 fix at this point since they have gone RTM with Windows 8.

The call to getComputedStyle on the clone source element worries me from a performance perspective because I think that will cause a reflow in many cases. It would be good to perf test it and if needed use a feature test for the bug to ensure that only the guilty browsers are hurt by any performance hit.

There's a very similar-sounding bug regarding .clone() in IE7 ... I wonder if it could be solved the same way? http://bugs.jquery.com/ticket/9777

The commits are kind of messed up, probably because you submitted the earlier pull from your master, but we can cherry-pick d5d8622 off there. If you haven't already you should probably clean up your master if you haven't already. http://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head

Yeah, I wondered if the PR came in clean or not. Arg. Yeah, I'll try what is listed on that SO link.

The fix comes down to adding the following before the call to elem.cloneNode( true );

// Fixes #8909 - By accessing one of the element's computed styles it breaks the
// connection with the cloned element's styles in IE9/10
if ( elem.nodeType === 1 && window.getComputedStyle ) {
    fix8908 = ( window.getComputedStyle( elem, null ) || {} ).backgroundImage;
}

As one of the cons I mentioned performance because it would run that code for any browser. I wasn't sure a good way to isolate just to IE9/10.

Good point about causing a reflow. I'm not sure about that one, but I can try to dig into that further.

I'll take a look at #9777 as you mentioned. It maybe be related, but as for the above bug it didn't show itself in IE7.

I figured this PR would probably wait since 1.8 is about finalized. Thanks for your feedback.

If you have any ideas on how to isolate this to IE9/10 I am all ears ;)

Changes Since the Initial Pull Request

Source Code Changes

I make a new test in the support module called clearCloneStyle that is true if the browser clears only the clone's style appropriate, but is false if it incorrectly clear's the original element's style as IE9 and IE10 do with 8 different styles. I picked the shortest style name of the 8 to test to keep the code short. The feature test intentionally doesn't use jQuery in order to keep the test as fast as possible.

support.clearCloneStyle = (function() {
    var source = document.createElement( "div" ),
        styleName = "backgroundClip",
        value = "content-box",
        clone;

    source.style[ styleName ] = value;
    clone = source.cloneNode( true );
    clone.style[ styleName ] = "";

    return source.style[ styleName ] === value;
})();

I am using the support.clearCloneStyle property in the fix right before the clone in manipulation.js

...
if ( jQuery.support.html5Clone || jQuery.isXMLDoc(elem) || !rnoshimcache.test( "<" + elem.nodeName + ">" ) ) {
+    // Fixes #8909 - By accessing one of the element's computed styles it breaks the
+    // connection with the cloned element's styles in IE9/10
+    if ( !jQuery.support.clearCloneStyle && elem.nodeType === 1 &&
+        window.getComputedStyle ) {
+        i = ( window.getComputedStyle( elem, null ) || {} ).backgroundPosition;
+    }

    clone = elem.cloneNode( true );
    ...
}
...

As I was retesting the code in IE6/7/8/9/10 I noticed that one of the styles (backgroundPosition) was not passing in IE9 :( The weird getComputedStyle call fixed all of the 8 broken styles in IE10, but only 7 of them in IE9. So, I had to add the following code in the style method of the css.js file to fix that outlier.

...         
// If a hook was provided, use that value, otherwise just set the specified value
if ( !hooks || !("set" in hooks) || (value = hooks.set( elem, value, extra )) !== undefined ) {
+    // IE9/10 Clearing Cloned Style Clear's Original Style. Fixes bug #8908
+    value = !jQuery.support.clearCloneStyle && value === "" && 
+        name.match( /backgroundPosition/ ) ? "0% 0%" : value;

    // Wrapped to prevent IE from throwing errors when 'invalid' values are provided
    // Fixes bug #5509
    try {
        style[ name ] = value;
    } catch(e) {}
}
...

Browsers Tested

I have run the above changes through the following browsers

Windows

• Chrome 22d/21.0b/20/19/18/17/16/15/14
• Firefox 15.0b/14/13/12/11/10/9/8/7/6/5/4/3.6/3
• IE 10/9/8/7/6
• Opera 12.5b/12.0/11.6/11.5/11.1/10.0
• Safari 5.1/5.0/4.0

Mac

• Chrome 20.0b/19/18/17/16/14
• Firefox 14.0b/13/12/11/10/9/8/7/6/5
• Opera 12/11.6/11.1
• Safari 5.1/5.0/4.0

Unit Test Changes

As I was testing the code in all the above browsers I added another assertion to the Unit Test to check if the style that was being cleared on the clone element was indeed being reset. Because of that addition assertion I made the following changes...

• Added a unit test to verify that the clone was indeed reset correctly
• Add the #ff0000 value to match the backgroundColor for Opera 11.1
• When a background-image is cleared in Firefox it sets the value to the full image path that it is inheriting
• Added the -1000px 0% value to match the backgroundPosition for Firefox 5.0
• Switched background-clip to padding-box because Safari 5.0 doesn't support that value

Summary of Changes

• I added the jQuery.support.clearCloneStyle check and used it before the elem.cloneNode( true ) to limit when a call to getComputedStyle occurs (IE9 / 10)
• I had to add another fix in the style method to fix the backgroundPosition style that wasn't fixed by the getComputedStyle above. This code path is also limited by the jQuery.support.clearCloneStyle check.
• I added another assertion to the Unit Test to verify that clearing out the style indeed resets it to an expected default value.

@dmethvin I just pulled in the changes and fixed the differences. Unfortunately I saw you said "rebase" after I pushed ;( So there are tons of commits shown.

Didn't actually close.

I haven't landed this yet, I just created a branch for @elijahmanor to review.

Woops, read the close, thought it needed to be closes/closed. :/

I realized there was no need to fix for backgroundPositionX/Y since they're not standard or supported across browsers (Firefox is the holdout, possibly Opera as well).