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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: tchize, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file, 1 obsolete file)
2.33 KB,
text/html
|
Details |
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•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Changed a confusing alert() message
Attachment #246696 -
Attachment is obsolete: true
Updated•18 years ago
|
Assignee: nobody → general
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Updated•18 years ago
|
Flags: in-testsuite?
Comment 3•18 years ago
|
||
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•17 years ago
|
||
This is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•