Closed
Bug 237783
Opened 20 years ago
Closed 20 years ago
document.textarea_ref.cloneNode(1) loses javascripted values.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mark, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file)
2.36 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 If a textarea has its value changed by javascript and then is cloned recursively using the cloneNode(1) function, the value of the child text node in the cloned object is the html loadtime value and not the javascripted one. Reproducible: Always Steps to Reproduce: Sample Code: <html> <body> <form name="f" id="f"> <textarea name="a" id="a">old value</textarea> </form> <form name="g" id="g"> </form> <script type="text/javascript"> document.getElementById('a').value = 'new value'; document.getElementById('g').appendChild(document.getElementById('a').cloneNode(1)); </script> </body> </html> Actual Results: The second (the clone) textarea displays a different value than the original. Expected Results: The values should both have been the same.
Comment 1•20 years ago
|
||
I'm pretty sure we already have a bug on this (it's fixed for <input>, but not <textarea>).
Summary: document.textarea_ref.cloneNode(1) loses javascripted values. → document.textarea_ref.cloneNode(1) loses javascripted values.
Whiteboard: DUPEME
Comment 2•20 years ago
|
||
For <input>, this was bug 224938 and bug 197294.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•20 years ago
|
||
This testcase is a bit complex (less is more), but i think things work as designed. When the value of a <textarea> or <input> is changed only the .value is changed. The childnode or the DOM-attribute will remain unchainged and thus reflect the .defaultValue of the form-element. This is what the DOM spec says to do at least for <input>. For <textarea>s the behaviour isn't defined, but we desided to let them behave the same for consistency.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•