197294 - [FIXr]The value of a cloned <input> is lost

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[rbs]

When an <input> node is cloned, whatever value was typed in is lost. The cloned
<input> goes back to the initial default value.

Will attach a simple testcase to demonstrate the problem.

Comment 1

[rbs]

Attachment: testcase to demonstrate the problem

Comment 2

[rbs]

Additional info: works as expected in IE6.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Cloning clones the node and its attributes.  IE incorrectly changes the "value"
attribute of the DOM node as you type.  So cloning "works" in IE.  Mozilla does
not change the attribute, so cloning loses the state....

Comment 4

[rbs]

I was maiking a demo where some parameters get created on the fly, and then
transferred to a set. Due to this bug, I am/was forced to stash the typed values
into private attributes rather than relying on the typed values directly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

*** Bug 224938 has been marked as a duplicate of this bug. ***

Comment 6

[Nathan Keynes]

According to the DOM level 1 HTML spec, value contains "The current form control
value". 

I would also note that if I manually loop through all form elements and copy the
values across by doing newElem.value = oldElem.value, this does work as
expected, which is to say it copies the current value (this is my current
workaround). I have to admit I'm confused as to why cloneNode should behave
differently from direct assignment.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Note the difference between "value" and "defaultValue" in that spec.  The latter
corresponds to an attribute and hence is copied automatically.  The former does
not, so needs special attention.  This is an explanation of why cloneNode acts
as it does in Mozilla, not a statement that it should act that way.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase with radio and checkbox

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible patch

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 134943 [details] [diff] [review]
Possible patch

jst, what do you think the behavior should be here?  Also, what, if anything,
should be done when a <textarea> is cloned?

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 134943 [details] [diff] [review]
Possible patch

+    case NS_FORM_INPUT_TEXT:
+    case NS_FORM_INPUT_PASSWORD:
+    case NS_FORM_INPUT_FILE:
+      if (GET_BOOLBIT(mBitField, BF_VALUE_CHANGED)) {
+	 // We don't have our default value anymore.  Set our value on
+	 // the clone.
+	 nsAutoString value;
+	 GetValue(value);
+	 // SetValueInternal handles setting the VALUE_CHANGED bit for us
+	 it->SetValueInternal(value, nsnull);
+      }

Looks reasonable to me, but what about hidden inputs? Don't they need this too?

r+sr=jst

Comment 12

[Boris Zbarsky [:bzbarsky]]

For hidden inputs we currently map the value property to the value attribute...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 15

[rbs]

<textarea> wasn't fixed and has been reported in bug 237783.