My bad! This is certainly a bug in the linter.
The fix is underway.

On 09.02.2018 12:35, Gijs Kruitbosch wrote:
> 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
>> <>
>> wrote:
>>> 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
>>>> release.
>>>> 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
>>>> prohibition.
>>>> -Kris
>>>> [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
dev-platform mailing list

Reply via email to