Enable createParserOptions, passing a sanitizer to trusted types

[noamr]

createParserOptions receives a SetHTML{Unsafe}Options and turns them into a TrustedParserOptions using the given method from the policy config.

This is the trusted-types part of #594

Note that this should only be merged when wired into the HTML standard, once the sanitizer is itself upstreamed.

---

Preview | Diff

[lukewarlow]

LGTM

[noamr]

I've made some changes:

• Some of the algorithm calls from "get Trusted Type compliant parser options" assumed stringifications. Made that algorithm do things on its own and passing a new object (repersented as an ordered map) instead.
• Allow passing throwIfMissing from the outside. streamHTMLUnsafe methods should throw if the policy cannot create parser options, while setHTMLUnsafe and friends can rely on createHTML.
• Support runScripts as per Add runScripts to SetHTMLUnsafeOptions whatwg/html#12495

(Note: this PR will fail build until we merge the latter)

[lukewarlow]

Are you able to fix the build failure now?

[noamr]

Are you able to fix the build failure now?

I'll revisit this once I have the HTML counterpart ready.

[annevk]

What is Stream?

[noamr]

It's a special value meaning that we don't have a string yet and we are going to stream the HTML. is null better? This seemed more descriptive.

[annevk]

Also, reportedly this impacts innerHTML and friends as well somehow? I think that warrants some examples.

[noamr]

Also, reportedly this impacts innerHTML and friends as well somehow? I think that warrants some examples.

Added prose and examples for this

[noamr]

(The build failure is in main, trying to resolve separately. Do you have an idea maybe @lukewarlow ?)

[evilpie]

In TrustedParserOptions sanitizer member is readonly, but a Sanitizer instance allows for internal modification. Isn't that unexpected?

Also I feel like we should probably always return a Sanitizer object, instead of one of three options? Otherwise it seems easy to accidentally write code (not sure what for though?) that only works with a subset.

[noamr]

In TrustedParserOptions sanitizer member is readonly, but a Sanitizer instance allows for internal modification. Isn't that unexpected?

It's a good point. I guess we need to return a clone of the underlying sanitizer if the getter is invoked so that you couldn't get a TrustedParserOptions and then mutate it.

Also I feel like we should probably always return a Sanitizer object, instead of one of three options? Otherwise it seems easy to accidentally write code (not sure what for though?) that only works with a subset.

Yea I was contemplating that. SGTM

[noamr]

Might be a silly question but why does the TrustedParserOptions need to expose the value of sanitizer and run scripts? Can it not be an opaque container than only web APIs can reach into? That way there's no weirdness about mutating a value that doesn't affect anything?

I guess it's kind of expected as a reflection, the same way you can stringify a TrustedHTML?

The mutability thing is a bit awkward but in most cases it wouldn't have any effect.
I'm also open to changing this reflection behavior, it's not material to the design.

[lukewarlow]

I have a feeling that a function is a better way to do the access for the sanitizer object. It feels more logical that a function returns a clone of an object rather than directly allowing mutations. But I'm curious for others thoughts here.

[noamr]

I have a feeling that a function is a better way to do the access for the sanitizer object. It feels more logical that a function returns a clone of an object rather than directly allowing mutations. But I'm curious for others thoughts here.

you mean something like sanitizer() that returns a fresh Sanitizer object in each call?
Yea that also works for me.

[noamr]

I have a feeling that a function is a better way to do the access for the sanitizer object. It feels more logical that a function returns a clone of an object rather than directly allowing mutations. But I'm curious for others thoughts here.

you mean something like sanitizer() that returns a fresh Sanitizer object in each call? Yea that also works for me.

Done

[noamr]

@lukewarlow having checked this, I think I have slight preference to keeping it as a getter, as it has the nice ergonomic benefit of being able to pass it to setHTML (and the other "safe" variant) as if it was a SetHTMLOptions - it reads the sanitizer property from the getter. If it's a method, it fails silently as it doesn't recognize that method as a sanitizer.

[lukewarlow]

Can we change it so that just works though? It feels like we could. I'm happy to leave it as a getter if that's preferred though.

[noamr]

Can we change it so that just works though? It feels like we could. I'm happy to leave it as a getter if that's preferred though.

Yea I guess its nicer as a method, and we can allow TrustedParserOptions in the IDL explicitly

[lukewarlow]

Other than the 3 changes above this PR LGTM. Haven't reviewed the HTML side yet.