Open bzbarsky opened 7 years ago
To be clear, this is the content-security-policy/blink-contrib/inline-style-allowed-while-cloning-objects.sub.html test.
Safari also seems to pass this test as written.
How does your change to Firefox affect the tests? I can certainly believe that Chrome is doing the wrong thing here, and if Firefox's behavior is more sane, I'm happy to adopt it.
How does your change to Firefox affect the tests?
It makes all the assertions of this test about cloned nodes fail, because the clone just gets the style attribute set as a string, which then needs to be parsed, which does a CSP check and doesn't actually do the parse. Though again, the specs in their current seems to be saying that it should be parsed but that its styles shouldn't be applied, or something along those lines....
I filed https://github.com/w3c/webappsec-csp/issues/212 on the spec side of this, because it needs clarification no matter what.
This test claims that if you set up a node with an inline style by manipulating .style and then clone the node then the clone should have the same .style and the same computed style.
But cloning as defined at https://dom.spec.whatwg.org/#concept-node-clone does not special-case style attributes in any way. And https://html.spec.whatwg.org/multipage/dom.html#the-style-attribute does say that the value should be parsed no matter what (pretty sure this is not what implementations do, by the way), but that the CSP check should also be done and if it fails the "style rules" (there aren't any in this case; just declarations) should not be applied. There are also no cloning steps defined in HTML that special-case the style attribute in any way.
So as far as I can tell, per spec the computed style should NOT be the same for the original element and the clone.
At the moment Firefox passes this test because it actually has special-casing for cloning of style attributes that just copies the parsed representation instead of copying the string as per spec, but I was removing that (because it's buggy in other unrelated ways) and ran into this test failure. As far as I can tell, the test is wrong. If the intent is that this test is right, then the specs need changes somewhere in here.
@mikewest am I missing something here? This looks like a Blink-contributed test, so presumably your implementation matches the test and not the spec...