Side navigation
#1836 closed bug (wontfix)
Opened October 23, 2007 04:10PM UTC
Closed December 14, 2007 04:33PM UTC
Last modified December 14, 2007 04:45PM UTC
.clone() not picking up form element names if set by .attr() in IE6
Reported by: | jamesvl | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.2.2 |
Component: | core | Version: | 1.2.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Name attributes, when dynamically set, are no longer getting cloned correctly in jQuery 1.2.1 on IE6.
Use case: When adding repeatable form elements to a form, I set the "original" elements' name to end with a '[]'. I then .clone() those elements and add them to the form if the user asks to.
Expect to see:
The newly .clone()d elements to also have their names end with '[]'.
Actually see:
The orignal elements' name only, if on IE6 and jQuery 1.2.1.
This behavior is ''not'' present on IE6 in jQuery 1.1.4, or with Firefox on either version of jQuery.
I copied my relevant code for an example here:
Attachments (0)
Change History (5)
Changed November 17, 2007 06:48AM UTC by comment:1
owner: | → davidserduke |
---|---|
status: | new → assigned |
Changed December 08, 2007 11:07PM UTC by comment:2
When we moved to DOM Level 2 event binding it created some issue for clone in IE. Mainly that event handlers bound via attachEvent are copied in IE. The strange thing about this is that if you call detach event, it will remove the event handlers from both the original and clone. After several iterations outerHTML seemed to solve the immediate problem of copying the event handlers while keeping the code clean. Unfortunately it brought some other issues along with it, as documented above.
Rev [4089] resolves the issue davidserduke mentioned using the list element example. The input name issue still remains because IE stores modifications to that attribute as a property and does not update the HTML.
Changed December 11, 2007 08:10AM UTC by comment:3
owner: | davidserduke |
---|---|
status: | assigned → new |
Changed December 14, 2007 04:33PM UTC by comment:4
resolution: | → wontfix |
---|---|
status: | new → closed |
IE is being extremely stubborn in trying to copy the name attribute. In order to fix this we would need to manually copy the name property from the original to the clone and do so for all the children as well. This could potentially be a huge performance hit. It is true that this issue is the result of not using .cloneNode in IE but the code we are using now solves the bigger issue of the events being copied (more like linked) from the original to the clone.
The work around is to insure you copy the name property if you are cloning form elements.
Changed December 14, 2007 04:45PM UTC by comment:5
Replying to [comment:4 brandon]:
The work around is to insure you copy the name property if you are cloning form elements.
Remember this work around is only needed if you are dynamically changing the name property on a form element.
This bug appears to be the result of changes in the clone() function and what IE returns for outerHTML.
Specific to this bug, IE is allowing the name change to the input but is not reflecting it in the outerHTML so in IE:
The new clone uses outerHTML for IE so cloned objects have name="oldname" instead of "newname" like used to happen in 1.1.4.
There are other cases I have seen with the problem too like:
So using the 1.2.1 clone that just gives an empty <li></li> with no text in it.
I think it would be worth thinking about going to back to the 1.1.4 method of cloning in IE.
I think that would fix this test case and the <li> clone problem. Does anyone remember why the change was made?