[Webkit-unassigned] [Bug 19524] New: Able to move nodes across documents
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jun 12 15:43:56 PDT 2008
https://bugs.webkit.org/show_bug.cgi?id=19524
Summary: Able to move nodes across documents
Product: WebKit
Version: 526+ (Nightly build)
Platform: PC
OS/Version: Mac OS X 10.5
Status: UNCONFIRMED
Severity: Normal
Priority: P2
Component: HTML DOM
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: danceoffwithyourpantsoff at gmail.com
Webkit currently enables a compat hack that allows you to move nodes between
documents. Here is the situation overall:
Node::checkAddChild special cases a node that is not inDocument() to be
compatible with Mozilla and Mac IE. The compatibility is because window.Option
internally creates a element using document.createElement(), meaning the node's
m_document is window.document. Apparently some people would use the Options()
constructor, and then try to add this node to another document (say an iframe).
Mozilla allows you to move nodes between documents, so this works, but I argue
this is completely broken. I have no idea about Mac IE. Windows IE does not
allow you to move nodes between documents, including the Options case.
Also, the hack is incorrect. The logic really means more of
"wasNeverInADocument" and not "inDocument". If you add a node to a document,
you can remove it, and then add it to a different document, which is clearly
incorrect. Adding a wasEverInADocument flag is also not correct, since this
allows any elements created via document.createElement, etc, to be attached to
a different document.
Also, checkAddChild will walk the nodes and setDocument it and all the
children, which is completely not the correct way to adopt a child.
checkAddChild should simply do a check, like the name implies, and no
modification should happen here! (really this should be a const method).
There are other bugs involving adopting nodes, but I would like to clean up the
code so there is only a single place where node adoption can occur
(document.adoptNode) so that the code will be more clear and we can fix the
adoption problems through a single path. I believe this is correct in terms of
the spec and the web. I don't think there are many cases of this new Options
problem, specially seeing that it doesn't work in IE.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list