Skip to main content

Bug Tracker

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:

http://dev.nosq.com/jquery_name_bug/

Attachments (0)
Change History (5)

Changed November 17, 2007 06:48AM UTC by davidserduke comment:1

owner: → davidserduke
status: newassigned

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:

$("input").attr("name", "newname");
alert($("input")[0].outerHTML); // <INPUT name=oldname>
alert($("input").attr("name")); // newname

<input name="oldname"/>

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:

alert($("li")[0].outerHTML); // <li>some text

<ul>
  <li>some text</li>
</ul>

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.

clone: function(events) {
  var ret = this.map(function() {
    return this.cloneNode(true);
  });

  ...

I think that would fix this test case and the <li> clone problem. Does anyone remember why the change was made?

Changed December 08, 2007 11:07PM UTC by brandon 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 davidserduke comment:3

owner: davidserduke
status: assignednew

Changed December 14, 2007 04:33PM UTC by brandon comment:4

resolution: → wontfix
status: newclosed

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 brandon 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.