document.textarea_ref.cloneNode(1) loses javascripted values.

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
--
minor
RESOLVED WORKSFORME
14 years ago
4 years ago

People

(Reporter: Mark, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 2

14 years ago
For <input>, this was bug 224938 and bug 197294.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

14 years ago
Created attachment 149386 [details]
Testcase based on reporter's code

Updated

14 years ago
Keywords: testcase

Updated

14 years ago
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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.