v157 · sanitizer api · configuration / inspection

Config inspector

The spec gives javascriptURLs three precise contracts: a canonicalisation default (absent → false for safe configs, true for unsafe ones), a return-value contract on setJavascriptURLs(allow) (true only when the stored value changed), and a removeUnsafe() override that forces it back to false. Each experiment below runs the real calls and prints the real get() output — or the real exception.

Probing…

Experiments

1 · Canonicalisation: what does a fresh config hold?

const s = new Sanitizer();          // safe default preset
s.get().javascriptURLs              // spec: false
const t = new Sanitizer({ javascriptURLs: true });
t.get().javascriptURLs              // spec: true (explicit value respected)

Expected per spec: false, then true.

Not run yet.

2 · Return-value contract: true = changed, false = no-op

const s = new Sanitizer();          // javascriptURLs: false
s.setJavascriptURLs(true)           // spec: true  (false → true, changed)
s.setJavascriptURLs(true)           // spec: false (already true, no-op)
s.setJavascriptURLs(false)          // spec: true  (true → false, changed)

Expected per spec: true, false, true.

Not run yet.

3 · removeUnsafe() forces javascriptURLs off

const s = new Sanitizer({ javascriptURLs: true });
s.removeUnsafe();                   // the step the safe methods always run
s.get().javascriptURLs              // spec: false — the explicit true was overridden

Expected per spec: false after removeUnsafe(). This is exactly why setHTML(input, {sanitizer:{javascriptURLs:true}}) still strips javascript: URLs.

Not run yet.

4 · The full canonical config, inspected

new Sanitizer({ javascriptURLs: true }).get()   // every key, as stored

Shows where javascriptURLs sits among comments and dataAttributes in the canonicalised dictionary (element/attribute lists truncated for readability; a toggle shows them in full).

Not run yet.

why the return value matters

Mutating methods on Sanitizer (allowElement, setComments, …) all report whether they changed the configuration. PR 12898 keeps setJavascriptURLs consistent with that family — and, in the same change, tightened setComments to the same "is allow" comparison. Code that builds configs incrementally can use the boolean to know whether a cached/compiled sanitizer needs rebuilding.

see also