3

In Firefox at least, when using cloneNode(true) on a dynamically or user-altered textarea or select element, the value property is not preserved (nor is the DOM altered to reflect dynamic changes), whereas with input elements, a change to the value property or by the user gets reflected in the DOM (so it is preserved upon the call to cloneNode). Why is there this distinction?

UPDATE:

  1. I meant to ask: Is this behavior prescribed in a spec somewhere? (or detailed in a bug report?)
  2. A sample is at: http://jsfiddle.net/9RSNt/1/
Brett Zamir
  • 14,034
  • 6
  • 54
  • 77
  • Can you reproduce the problem in http://jsfiddle.net? – Ram Jan 11 '14 at 06:53
  • Sorry, misleading title and info before--now updated....The issue is only with cloning--the properties don't copy over as they do with input elements... – Brett Zamir Jan 11 '14 at 13:04

1 Answers1

3

I suspect the difference arises because textarea and selects' values are determined by their node content. Modifying the control's value modifies their DOM properties, but not their node content, so when you clone them, the clone has the value of the original element.

You can get around this by updating their node content on the change event:

// textarea
$("textarea").change(function() { $(this).text($(this).val()); });

// select
$("select").change(function() {
    var sel = $(this).children(":selected");
    $(this.children).not(sel).removeAttr("selected");
    sel.attr("selected", "selected");
});

http://jsfiddle.net/emr2w/8/

EDIT:

There are a number of Mozilla bug cases on this (some resolved and some not), but any mention of the actual specs are few and far between. It seems that the the behavior of the value property after a cloneNode() may be a gray area that is not clearly defined in the spec. After all, the purpose of cloneNode() is to clone a DOM node, and not necessarily its object state.

https://bugzilla.mozilla.org/show_bug.cgi?id=197294
https://bugzilla.mozilla.org/show_bug.cgi?id=230307
https://bugzilla.mozilla.org/show_bug.cgi?id=237783

JLRishe
  • 99,490
  • 19
  • 131
  • 169
  • Yeah, thanks--I was just thinking though that since the actual attribute is getting modified when you change the input value, not just the JavaScript property, it would make sense for the value to dynamically update the others. It would avoid the need for such serialization (as is the purpose of some code I'm writing). +1 for the right idea... – Brett Zamir Jan 11 '14 at 09:07
  • Sorry, that was not correct, the attribute does not get modified in the DOM even for inputs--I should have said the actual property is getting modified including upon cloneNode, so it would make sense for it to get copied for the others. – Brett Zamir Jan 11 '14 at 09:40
  • What serialization are you referring to? – JLRishe Jan 11 '14 at 11:18
  • My code is doing its own serialization of the form to a string, and it would be safer and easier for me to be able to copy the properties if they were maintained after a cloning. Sorry, it's not important to this discussion. – Brett Zamir Jan 11 '14 at 13:07
  • @BrettZamir Ok, well if you use my simple workaround above, the value will be maintained after cloning. So does that solve your issue? – JLRishe Jan 11 '14 at 13:28
  • Sorry, but as per my update, I'm really more looking for a spec (or bug report) on this as far as a final answer. – Brett Zamir Jan 11 '14 at 13:50
  • I already provided three bug reports. Besides, the behavior is what it is, so shouldn't you be more concerned with working with the behavior as it currently exists? – JLRishe Jan 11 '14 at 13:52