Closed Bug 361989 Opened 18 years ago Closed 17 years ago

cloneNode(true) does not copy eventlisteners registred to nodes

Categories

(Core :: DOM: Core & HTML, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: tchize, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

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
Attached file Testcase (obsolete) —
Keywords: testcase
Attached file demonstration testcase
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
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.
This is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.