Missing Trusted Type support data for various sinks

[lukewarlow]

What type of issue is this?

Missing compatibility data

What information was incorrect, unhelpful, or incomplete?

Various APIs in BCD have an "accepts_TrustedXXX" entry which says which version of a browser accepts TrustedHTML, TrustedScript or TrustedScriptURL in a given sink. Only some of the applicable APIs have this data though.

What browsers does this problem apply to, if applicable?

No response

What did you expect to see?

I expected all TT sinks to have this data (or none of them).

Did you test this? If so, how?

N/A

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

No response

MDN URL

No response

MDN metadata

No response

[lukewarlow]

As an example there's https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts which doesn't have this data but is a TT sink.

One example of a place this would be particularly useful is https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/Function which doesn't actually accept TrustedScript values correctly in Chromium (they're always stringified and put through the default policy if one exists), so it's at best partial support.

Another example is document.write(ln) where Chrome's implementation is limited in comparison to WebKit's (and the specs), it only accepts a single TrustedHTML param.

It's also possible that a separate entry of "enforces Trusted Types" would be appropriate, for some sinks its conditional on various conditions. This would better indicate state such as Chrome's new Function() support, where it enforces TT but doesn't accept TrustedScript.

A (hopefully exhaustive) list of applicable APIs:

• eval()

• new Function() (and all of it's variants such as AsyncFunction)

• Document.parseHTMLUnsafe()

• document.writeln()

• document.write()

• document.execCommand()

• element.innerHTML

• element.outerHTML

• element.setHTMLUnsafe()

• element.insertAdjacentHTML()

• range.createContextualFragment()

• shadowRoot.innerHTML

• shadowRoot.setHTMLUnsafe()

• iframe.srcdoc

• domParser.parseFromString()

• script.text

• script.textContent - (This is actually mirrored onto the HTMLScriptElement interface as of latest spec and in WebKit)

• script.innerText - (This is actually mirrored onto the HTMLScriptElement interface as of latest spec and in WebKit)

• svgAnimatedString.baseVal - This always accepts TrustedScriptURL but it only enforces TT when it's SVGScriptElement.href.baseVal (though actually in Chrome it is incorrectly enforced when SVGScriptElement.className.baseVal)

• serviceWorkerContainer.register()

• worker.importScripts()

• new Worker()

• new SharedWorker()

• embed.src - no longer needed by the spec and as such NOT implemented in WebKit (probably doesn't need documenting)

• object.data

• object.codeBase - not documented on MDN, no longer needed by the spec and as such NOT implemented in WebKit (probably doesn't need documenting)

• setTimeout() - Also on Worker

• setInterval() - Also on Worker

Chromium also erroneously accepts TrustedScript (and enforces TT) on before(), after(), replaceWith(), prepend(), append() and replaceChildren() when called on HTMLScriptElements

There's also some general coverage on both HTMLScriptElement and SVGScriptElement when their contents are updated not via an approved sink (in the case of SVG there is no approved sink so their content is only trusted via the parser).