Skip to main content

Bug Tracker

Side navigation

#11014 closed bug (worksforme)

Opened December 13, 2011 05:03PM UTC

Closed December 14, 2011 03:59AM UTC

Last modified February 02, 2012 02:57PM UTC

.Clone Behaviour Changes in IE7 After Installing KB2497640

Reported by: Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.5.2
Keywords: Cc:
Blocked by: Blocking:

Using IE7 on Window XP SP3 after installing the KB2497640 (MS11-018) security update, cloning of items with jQuery 1.5 appears to work incorrectly. Downgrading to jQuery to 1.4 or removing KB2497640, appears to resolve the problem. The issue is not reproducible on other browsers. Upgrading to 1.6+ is not an option due to #9777 which actually makes the problem worse in some situations.

Our application uses clone() for a large amount of templating, so this bug and #9777 make the application unusable in IE7 with any jQuery version after 1.4. Suggesting to our clients that they must uninstall critical security updates is also not a viable option.

Steps to Reproduce

A stripped down example can be found at:

1. The page should initially load with just an Apply Template button visible

1. Clicking the button should cause any existing items in the (initially empty) list to be removed and a number of new items will be inserted based on a template LI node.

1. In any browser but IE7 + KB2497640, you can click the button as many times as you like and it continues to display the list items.

1. With IE7 + KB2497640, after two or three clicks of the button (the number of clicks isn't always consistent), list items will no longer be added, leaving you with an empty list.

From my investigation, it appears as though the selectors are no longer able to find the template nodes by ID. If I modify the selectors to find them using classes or element types, I can still find the elements, so they do still exist in the DOM.

Compatibility Summary

|| || jQuery 1.4 || jQuery 1.5 ||

|| IE7 || OK || OK ||

|| IE7 + KB2497640 || OK || Fail ||

|| Other browsers || OK || OK ||

Note that while this sample not not exhibit the problems from #9777 when using jQuery 1.6+, the actual production application does.


This problem only occurs in IE7 with KB2497640 installed when using jQuery 1.5. The exact same site without that security update behaves as expected. I have only tried this on Windows XP SP3 as I do not have a Vista installation to test with.

The details of the security update can be found at:

Attachments (0)
Change History (3)

Changed December 14, 2011 03:59AM UTC by dmethvin comment:1

resolution: → worksforme
status: newclosed

I can see the problem happen with a fully patched IE7 and jQuery 1.5.2, but we don't attempt to patch old versions of jQuery. I do not see the problem occur with the 1.7.1 or with 1.6.4.

I understand what you mean about #9777 but we have not been able to find a way around that problem. If you have some insights about that issue it may be easier to fix that and upgrade to a later version.

Since the issue occurred when this patch was applied, you could try contacting Microsoft to see if they can resolve the problem. If your clients are using IE7 they are most likely a corporate customer and paying quite a bit of money to Microsoft for support.

I'm going to mark this particular issue as worksforme since it does not occur in any recent version, but we can continue to work on #9777.

Changed February 02, 2012 02:54PM UTC by skapigsf comment:2

Ran into this issue with 1.6.4 and IE7. Debugging revealed that find() using the id selector on cloned elements would start returning the original element even though the id on it is not set. getElementById() works correctly, so this probably should be considered a jQuery defect.

Changed February 02, 2012 02:57PM UTC by dmethvin comment:3

If you can reproduce it on the jquery-git version please post a link to the test case.