WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
62737
attribute parsing manipulates document structure without knowing node insertedIntoDocument
https://bugs.webkit.org/show_bug.cgi?id=62737
Summary
attribute parsing manipulates document structure without knowing node inserte...
Abhishek Arya
Reported
2011-06-15 10:20:11 PDT
Testcase 1: <html> <body> <a href="
http://notvisited.com
">google link - RED FAILS, GREEN PASSES</a> <script> var body1 = document.body; document.linkColor = "green"; var body2 = body1.cloneNode(true); body2.link = "red"; body1.vLink = "blue"; // This just helps to recalc style on the document. </script> </body> </html> Testcase 2: <html> <body> <a href="
http://notvisited.com
">google link - RED FAILS, GREEN PASSES</a> <script> var body1 = document.body; document.linkColor = "green"; var body2 = document.createElement('body'); body2.link = "red"; body1.vLink = "blue"; // This just helps to recalc style on the document. </script> </body> </html>
Attachments
Add attachment
proposed patch, testcase, etc.
Abhishek Arya
Comment 1
2011-06-15 10:29:33 PDT
This happens in two scenarios 1. Clone nodes (they are not supposed to be in document and should have null parents)
https://developer.mozilla.org/En/DOM/Node.cloneNode
http://w3.org/TR/DOM-Level-2-Core/core.html#ID-3A0ED0A4
2. Nodes created via document.createElement, but not attached yet via appendChild or similar methods. These testcases are specific to HTMLBodyElement, but i think this problem can be in any element which manipulates document()->something inside parseMappedAttribute.
David Kilzer (:ddkilzer)
Comment 2
2011-06-27 09:12:22 PDT
<
rdar://problem/9681173
>
Alexey Proskuryakov
Comment 3
2011-12-30 12:47:03 PST
Duplicate of
bug 59343
?
Abhishek Arya
Comment 4
2012-01-03 09:19:37 PST
(In reply to
comment #3
)
> Duplicate of
bug 59343
?
I don't see a correlation b/w this bug and
bug 59343
. ccing Michael, in case i am missing something.
Darin Adler
Comment 5
2012-01-08 21:49:02 PST
(In reply to
comment #1
)
> These testcases are specific to HTMLBodyElement, but i think this problem can be in any element which manipulates document()->something inside parseMappedAttribute.
Those should be very rare. I think this is a body-element-specific thing. That code assumes that the element is “the” body element for a document, but it’s really just “a” body element and not even in the document’s tree. Other elements would typically not do that sort of thing. I think the title of this bug is not really good. The function insertedIntoDocument isn’t really the point. The point is that a body element is modifying the document, assuming it’s the body element of that document. An inDocument check might be sufficient, we also might want to simply check if this == document()->body(). The question that could drive that decision is whether we can end up with multiple HTMLBodyElement objects in the DOM tree at once, and if so, what is the correct behavior.
Adam Barth
Comment 6
2012-01-08 22:07:54 PST
Its easy to have multiple HTMLBodyElements in the DOM tree. Just createElement them and call appendChild.
Darin Adler
Comment 7
2012-01-08 22:37:12 PST
(In reply to
comment #6
)
> Its easy to have multiple HTMLBodyElements in the DOM tree. Just createElement them and call appendChild.
Makes sense. This bug is really about these attributes on body elements other than the actual body element. Being in document tree vs. not in the document tree isn’t important. To get this right, we want code that handles various corner cases correctly, including things like body elements that are <frameset> rather than <body>, removing one body element so another element becomes the body element, inserting a body element that already has attributes, and so on. Shouldn’t be too hard to write, but quite different from what we have now.
Ahmad Saleem
Comment 8
2022-08-09 15:32:24 PDT
Test Case 1 -
https://jsfiddle.net/knt961qv/
Test Case 2 -
https://jsfiddle.net/bzevxj0n/
In both above cases - Safari 15.6 on macOS 12.5 and Chrome Canary 106 show the color as "RED" while Firefox Nightly 105 show it as "Green" to indicate that the test is passed. It seems similar to
bug 61697
as well.
rniwa@webkit.org
- is fix for
bug 156849
going to have any impact on this?
Ryosuke Niwa
Comment 9
2022-08-10 00:06:08 PDT
(In reply to Ahmad Saleem from
comment #8
) >
>
rniwa@webkit.org
- is fix for
bug 156849
going to have any impact on this?
Nope. That change only affects how the value of presentational attributes is parsed.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug