Sorry about the waste of time. :-(

Re: difficulty: it depends on your measure of 'very'. Internally the sanitization is whitelist-based. It is used in many places (not just for chrome-privileged docs), where it would be wrong to show warnings (possibly very *many* warnings!). It may be possible to add a flag to the sanitizer to log warnings for every removed attribute/element, and to pass that explicitly from the callsites that Kris added. It'd be worth filing a bug for that.

To be honest, I would have expected there to have been an eslint error if using innerHTML/createContextualFragment with anything other than a fixed string, which might have saved you a lot of headache. If that linter isn't catching createContextualFragment, then we need to fix the linter so that it does. If you were using a fixed string that got sanitized, can you point me to the bug/patch that you're working on? I'm having trouble thinking of cases where we use innerHTML with fixed content that would get sanitized in this way, without any injection/replacement, but perhaps I'm missing something.

~ Gijs

On 09/02/2018 02:18, Brendan Dahl wrote:
Would it be very difficult to warn when something is sanitized and removed?

I wasted a good deal of time trying to figure out why
createContextualFragment wasn't working.

On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch <>

FWIW, if you're running into this with the usecase "I have a localized
string that needs to have links (or other markup) in it" and were formerly
using getFormattedString combined with innerHTML, we now have a utility
method that can help a little bit. Rather than hand-rolling splitting the
string etc., on nightly you can use BrowserUtils.getLocalizedFragment as
a replacement. Given a document, raw string (fetch using getString /
GetStringFromName instead of the "formatted" APIs), and DOM nodes to
insert, it'll produce a DocumentFragment that you can
appendChild/insertBefore etc., take care of splitting your strings for you,
and will work with both indexed (%1$S) and non-indexed (%S) replacement
points in the localized string. In the further future, I expect this type
of problem will go away entirely because of Fluent.

~ Gijs

On 02/02/2018 07:13, Kris Maglione wrote:

As of bug 1432966, any HTML injected into chrome-privileged documents[1]
is automatically sanitized to remove any possibility of script execution.
The sanitization is whitelist-based, and only allows a limited set of HTML
elements and attributes. All scripts, XUL nodes, or privileged URLs will
automatically be removed. This change has been uplifted all the way to 58

If you're thinking about writing new code that injects HTML strings into
chrome-privileged documents, please think again. Unless it's extremely
simple, it probably won't be compatible with these changes (and will also
be rejected by our default ESLint rules).

Existing HTML injection in chrome documents is being gradually removed.
Once that's done, the sanitization may be replaced with an outright


[1]: Using the usual HTML fragment creation methods such as `innerHTML`,
`outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
notably, when using document.write().
firefox-dev mailing list

firefox-dev mailing list

dev-platform mailing list

Reply via email to