cloneNode(true) does not copy eventlisteners registred to nodes

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
13 years ago
a month ago

People

(Reporter: tchize, Unassigned)

Tracking

({testcase})

1.8 Branch
x86
Linux
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

2.33 KB, text/html
Details
(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux; X11; i686; fr) KHTML/3.5.5 (like Gecko) (Kubuntu)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)

If you use cloneNode(true) on a DOM Element that has a <A> somewhere in it's child, event listener registered to this <A> element get lost during copy. As a result, this is not a full copy of the node and can lead to copy node being unfonctionnal. This happens if the event are registered with the old node.onclick=... way or the more recent node.addEventListener("onclick",...) way.

Reproducible: Always

Steps to Reproduce:
1.Create an anchor node
2.Register an eventlistener to this node
3.Clone the node.
4.The clone and neither of it's child has eventlistener registered to it.

Actual Results:  
Cloned nodes are inactive, they have no events

Expected Results:  
Cloned nodes should have event listener registered to it
(Reporter)

Comment 1

13 years ago
Posted file Testcase (obsolete) —
(Reporter)

Updated

13 years ago
Keywords: testcase
(Reporter)

Comment 2

13 years ago
Changed a confusing alert() message
Attachment #246696 - Attachment is obsolete: true
Assignee: nobody → general
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

Updated

13 years ago
Flags: in-testsuite?
That's a real stretch of the cloneNode definition.  The first paragraph of the cloneNode definition, in W3C DOM Level 3 Core, states:

"Returns a duplicate of this node, i.e., serves as a generic copy constructor for nodes. The duplicate node has no parent (parentNode is null) and no user data. User data associated to the imported node is not carried over. However, if any UserDataHandlers has been specified along with the associated data these handlers will be called with the appropriate parameters before this method returns."

The next paragraph opens with:

"Cloning an Element copies all attributes and their values, including those generated by the XML processor to represent defaulted attributes, but this method does not copy any children it contains unless it is a deep clone..."

But event listeners added via addEventListener don't count.

Dom 2 Events (another W3C Recommendation) is pretty clear:

"When a Node is copied using the cloneNode method the EventListeners attached to the source Node are not attached to the copied Node. If the user wishes the same EventListeners to be added to the newly created copy the user must add them manually."

DOM 3 Events (a Note) is even clearer:

"Copying a Node, with methods such as Node.cloneNode or Range.cloneContents, does not copy the event listeners attached to it. Event listeners must be attached to the newly created Node afterwards if so desired."

So the second half of the testcase is INVALID.  It's debatable whether the first half is INVALID as well, but I tend to think it is.

Comment 4

12 years ago
This is INVALID.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.