Closed Bug 197294 Opened 20 years ago Closed 19 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.6beta

People

(Reporter: rbs, Assigned: bzbarsky)

References

Details

Attachments

(3 files)

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.
Additional info: works as expected in IE6.
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....
Whiteboard: DUPEME
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.
*** Bug 224938 has been marked as a duplicate of this bug. ***
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.
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.
Attached patch Possible patchSplinter Review
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?
Attachment #134943 - Flags: superreview?(jst)
Attachment #134943 - Flags: review?(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
Attachment #134943 - Flags: superreview?(jst)
Attachment #134943 - Flags: superreview+
Attachment #134943 - Flags: review?(jst)
Attachment #134943 - Flags: review+
For hidden inputs we currently map the value property to the value attribute...
Taking.
Assignee: john → bz-vacation
Priority: -- → P1
Summary: The value of a cloned <input> is lost → [FIXr]The value of a cloned <input> is lost
Whiteboard: DUPEME
Target Milestone: --- → mozilla1.6beta
Checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
<textarea> wasn't fixed and has been reported in bug 237783.
Blocks: 237783
You need to log in before you can comment on or make changes to this bug.