Improve test coverage for DOM integration in WPT

[koto]

• https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setAttribute.html needs

  • test with an attribute (e.g. HTML's srcdoc) node created in a different realm. It should be rejected when imported and added to an iframe in the current, TT-enforcing realm.
  • test that a default policy's value, and not the value in the setAttribute argument is propagated to the MutationObserver https://jsfiddle.net/014ze36t/2/

• https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setAttributeNS.html needs

  • allowing iframe.setAttributeNS(null, 'SrcDoc') attribute (or a similar mixed-case test for HTML's attributes).

#418 (comment) and #418 (comment) for context.

[lukewarlow]

web-platform-tests/wpt#44266 - PR to add coverage for setHTMLUnsafe and parseHTMLUnsafe

[mbrodesser-Igalia]

https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setAttribute.html needs

* test with an attribute (e.g. HTML's `srcdoc`) node created in a different realm. It should be rejected when imported and added to an iframe in the current, TT-enforcing realm.

@koto AFAIK, such attribute nodes can only be gotten from a different realm, if the realm corresponds to the same origin. E.g. via an <iframe>. However, the last non-goal at https://w3c.github.io/trusted-types/dist/spec/#non-goals is:

"Prevent malicious authors of the web application’s JavaScript code from being able to bypass the restrictions; attempting to protect against malicious authors would result in an overly complex and not-practical design."

Is the assumption that same-origin documents may correspond to multiple authors, from which only one may be malicious?

[koto]

It's only testing the mechanics of the DOM integration. We have to pick a realm to run the TT checks against, and this is a way to test that we're picking the element's document realm. We're not extending the threat model to cover cross-documents vector, the fact that it might be used to block attaching foreign (same-origin) attribute node to a local element is just a consequence of the mechanisms we chose.

[mbrodesser-Igalia]

https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setAttribute.html needs

* test with an attribute (e.g. HTML's `srcdoc`) node created in a different realm. It should be rejected when imported and added to an iframe in the current, TT-enforcing realm.

@koto: to be precise, the test should be added to a file like <block-string-assignment-to-Element-setAttributeNode.html>, since setAttribute() requires a string (https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute#syntax), and Attr nodes don't have a stringifier (https://dom.spec.whatwg.org/#interface-attr). Correct?

[koto]

Yes

[mbrodesser-Igalia]

Reopening until web-platform-tests/wpt#44323 is merged.

[mbrodesser-Igalia]

An additional test for web-platform-tests/wpt#44323 (review) is required.

[mbrodesser-Igalia]

Reopening to address #425 (comment).

[mbrodesser-Igalia]

With https://phabricator.services.mozilla.com/D231921 all scenarios are now covered.