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 >> <gijskruitbo...@gmail.com> >> 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-...@mozilla.org >>>> https://mail.mozilla.org/listinfo/firefox-dev >>>> >>> >>> >>> _______________________________________________ >>> firefox-dev mailing list >>> firefox-...@mozilla.org >>> https://mail.mozilla.org/listinfo/firefox-dev >>> > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
