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)

x86
Windows 2000
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mark, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

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.
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
For <input>, this was bug 224938 and bug 197294.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Depends on: 197294
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
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: