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

RESOLVED FIXED in mozilla1.6beta

Status

()

Core
DOM: Core & HTML
P1
normal
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: rbs, Assigned: bz)

Tracking

Trunk
mozilla1.6beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 117158 [details]
testcase to demonstrate the problem
(Reporter)

Comment 2

15 years ago
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
(Reporter)

Comment 4

15 years ago
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. ***

Comment 6

15 years ago
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.
Created attachment 134942 [details]
Testcase with radio and checkbox
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
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 15

14 years ago
<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.