Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1836 closed bug (wontfix)

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

Change History (5)

comment:1 Changed 12 years ago by davidserduke

Owner: set to 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?

comment:2 Changed 12 years ago by brandon

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.

comment:3 Changed 12 years ago by davidserduke

Owner: davidserduke deleted
Status: assignednew

comment:4 Changed 12 years ago by brandon

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.

comment:5 in reply to:  4 Changed 12 years ago by brandon

Replying to 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.

Note: See TracTickets for help on using tickets.