Integrate Trusted Types enforcement into attribute handling

[lukewarlow]

This updates the DOM spec to add the neccessary integration with the Trusted Types spec to ensure attribute values are protected by TT enforcement.

The Element.setAttribute() and Element.setAttributeNS() method steps, along with the "set an attribute" algorithm (which is used by Element.setAttributeNode(), Element.setAttributeNodeNs(), NamedNodeMap.setNamedItem() and NamedNodeMap.setNamedItemNs()), and the "set an existing attribute value" algorithm (which is used by Attr.value, Attr.nodeValue, and Attr.textContent), are all updated to allow Trusted Type's to verify the updated attribute value before it's set.

The IDL definitions for Element.setAttribute() and Element.setAttributeNS() are both updated to take a TrustedType object (can be all 3 types) in addition to DOMString, these two methods are the only "blessed" way to update an attribute value when Trusted Types is enforced.

See and #789. Supercedes #809 and #1247

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/trusted-types
• Implementation bugs are filed:
  • Chromium:https://bugs.chromium.org/p/chromium/issues/detail?id=739170
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1508286
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=266630
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[lukewarlow]

This is a clone of #1247 where I will finish any outstanding work to get this across the line

[lukewarlow]

See also #1258 which is another integration point with the DOM spec that we need for TT.

[lukewarlow]

I think I've addressed all the comments from #1247.

I do want to point out Chrome and WebKit don't (or at least not in a way obvious to me) 100% follow the flow of the spec and as a result this may result in differences specifically in weird cases with attribute mutation.

So that bit especially it would be good to get feedback on.

It's also worth being aware that like Chromium's implementation this spec means that certain ways to update a nodes value don't work with a trusted type object as a user might expect. (e.g. iframe.getAttributeNode('srcdoc').value = trustedHTMLObj; will throw unless allowed by a default policy). I think in pratice this will be fine, and in some cases is the only real option we have without nodes keeping track of whether they're trusted or not (which would add lots of complexity)

[annevk]

This change is either incomplete or makes many cosmetic changes that would be best proposed separately as they confuse me quite a bit.

[lukewarlow]

This change is either incomplete or makes many cosmetic changes that would be best proposed separately as they confuse me quite a bit.

Apologies I thought I'd reverted all of these changes but I missed a few, it's because I changed stuff and then changed it back and this led to some wonky diffs. Have hopefully reverted all of these unnecessary changes

[lukewarlow]

@otherdaniel, @annevk , and @smaug---- regarding the case where the default policy changes assumptions about the existence of an attribute mid-way through what would you prefer the spec say to do? Currently I've specced to throw, but Chromium currently re-looks up the index (spec doesn't explicitly work on an index basis but Chromium and WebKit do)

[annevk]

Attributes are stored in a list and those do have indices per Infra. What am I missing?

[lukewarlow]

Sorry I mean algorithmically the spec and implementations don't follow the same flow. So it's trickier to reason between the spec and implementation. This might just be my lack of familiarity with these APIs too.

[annevk]

The path of least resistance is prolly matching Chromium. Introducing new paths that throw is always risky. If you are looking for guidance as to how, I'd need quite a bit more context to provide helpful suggestions.

[lukewarlow]

@otherdaniel I believe this spec PR fully matches your proposals to call TT as early as possible now. If you've got time I'd be thankful for a review to get another pair of eyes on this.

[annevk]

This is indeed a whole bit more straightforward to read through.

[annevk]

@fred-wang @otherdaniel if you could reply to @lukewarlow's comment above that would help a lot, thanks! @smaug---- did you want to have another look at this PR as well?

[fred-wang]

🎉

[annevk]

Indeed, thanks a lot @lukewarlow for finishing this and @smaug---- for his careful reviews! And of course everyone else that helped improve Trusted Types integration over the years. 🎉