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>
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.
<rdar://problem/9681173>
Duplicate of bug 59343?
(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.
(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.
Its easy to have multiple HTMLBodyElements in the DOM tree. Just createElement them and call appendChild.
(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.
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?
(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.