Skip to content
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

Sanitizer constructor needs to set configuration with safe #273

Open
evilpie opened this issue Mar 12, 2025 · 1 comment
Open

Sanitizer constructor needs to set configuration with safe #273

evilpie opened this issue Mar 12, 2025 · 1 comment
Labels
bug editorial editorial spec changes
Milestone

Comments

@evilpie
Copy link
Contributor

evilpie commented Mar 12, 2025

Regression from #254. The normal Sanitizer constructor does not set the safe parameter.

  1. Let valid be the return value of setting configuration on this.

https://wicg.github.io/sanitizer-api/#sanitizer-constructor

To set a configuration, given a dictionary configuration, a boolean safe, and a Sanitizer sanitizer:

https://wicg.github.io/sanitizer-api/#sanitizer-set-a-configuration

It's actually not immediately obvious to me if we should default to false or true. I think whatever we choose we would end up in a situation where we either break setHTML(html) == setHTML(html, {sanitizer: new Sanitizer()}) or setHTMLUnsafe(html) == setHTMLUnsafe(html, {sanitizer: new Sanitizer()}), because at the construction time we don't know which variant safe/unsafe is going to be called.
We might have discussed this already, though.

@annevk
Copy link
Collaborator

annevk commented Mar 12, 2025

I think it should depend on whether or not "default" ends up being passed (including when it's the default value). In that case it should be safe. Otherwise it should be unsafe.

setHTMLUnsafe(html) == setHTMLUnsafe(html, {sanitizer: new Sanitizer()})

This is already not the same as Sanitizer uses "default". You'd have to pass { } as constructor argument instead. Coupled with my rule above that would make this work.

@mozfreddyb mozfreddyb added bug editorial editorial spec changes labels Mar 17, 2025
@mozfreddyb mozfreddyb added this to the v1 milestone Mar 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug editorial editorial spec changes
Projects
None yet
Development

No branches or pull requests

3 participants