-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test for importing a srcdoc
attribute node from a non-TT realm to a TT iframe element throws
#44323
Add test for importing a srcdoc
attribute node from a non-TT realm to a TT iframe element throws
#44323
Conversation
Stumbled on #44352, which either needs to be fixed or worked around. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would help to have a pointer where the throwing is defined. I didn't see it in the linked issue either.
<body> | ||
<div id="nonSVGTestElements"> | ||
<iframe srcdoc="v"></iframe> | ||
<embed src="v"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For embed
and object
the expectation needs to be different right, per recent events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably you refer to w3c/trusted-types#486? Yes. Presumably more tests will have to be adapted; it seems cleaner to do that collectively in w3c/trusted-types#486.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm planning to go through the test suite and probably just removing most references to embed and object. With potentially one left to make sure that they're not enforcing TT restrictions.
So feel free to just not add them to this test, or to add them and I can remove them them in my PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to loop back here I've started WebKit/WebKit#26554
So it would be best if no new usages of embed or object were added.
Indeed not obvious. The throwing stems from: whatwg/dom#1247 (diff: https://whatpr.org/dom/1247/6a9b5a2...10ce041.html) which invokes https://w3c.github.io/trusted-types/dist/spec/#validate-attribute-mutation. |
trusted-types/block-string-assignment-to-Element-setAttributeNode.html
Outdated
Show resolved
Hide resolved
9af8771
to
9839909
Compare
trusted-types/Element-setAttribute-respects-Elements-node-documents-globals-CSP.html
Show resolved
Hide resolved
…to a TT iframe element throws First step to fix <w3c/trusted-types#425>. Will add separate commits for the other tests requested at above ticket.
…l> and further simplify it
…s created in a non-TT enforcing realm are imported to a TT-enforcing realm See <https://w3c.github.io/trusted-types/dist/spec/#validate-attribute-mutation>. This excludes tests for <https://w3c.github.io/trusted-types/dist/spec/#enforcement-in-event-handler-content-attributes> which will have to be added once that part of the spec is propagated to the HTML spec. The remaining tests mentioned at <w3c/trusted-types#425 (comment)> will be added in separate commits.
…ment`'s and `sourceAttr`s realms differ
…e element's node document's global's CSP Requires web-platform-tests#45405 to be fixed.
9839909
to
dfd95a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks like the correct test.
I wonder if we should also test the inverse. That when you take an element out of a TT global, TT is no longer enforced for it.
I don't know how relevant that scenario is. @koto: any experience with that? |
It's relevant for ensuring the specification is implemented correctly. |
True; but is that scenario actually relevant in practice? |
That does not matter for conformance tests. The whole point is that we can't know what websites might do and might rely on. |
Agreed. Added w3c/trusted-types#425 (comment) so that another test will be added. |
@annevk: can you please merge this test, I lack rights. |
First step to fix w3c/trusted-types#425.
Will add separate commits for the other tests requested at above ticket.