<div dir="ltr">The linter does pick up the error. This was something I was testing locally. I generally don't think of running the linter to figure out why something isn't working (maybe I should be as it becomes more powerful?). However, I don't imagine I'll be the last developer to try to a use an API that is a web standard and be confused why it doesn't work though. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 3:35 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry about the waste of time. :-(<br>
<br>
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.<br>
<br>
To be honest, I would have expected there to have been an eslint error if using innerHTML/createContextualFrag<wbr>ment 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.<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs</font></span><span class=""><br>
<br>
On 09/02/2018 02:18, Brendan Dahl wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Would it be very difficult to warn when something is sanitized and removed?<br>
<br>
I wasted a good deal of time trying to figure out why<br>
createContextualFragment wasn't working.<br>
<br>
On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>><br>
wrote:<br>
<br>
</span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW, if you're running into this with the usecase "I have a localized<br>
string that needs to have links (or other markup) in it" and were formerly<br>
using getFormattedString combined with innerHTML, we now have a utility<br>
method that can help a little bit. Rather than hand-rolling splitting the<br>
string etc., on nightly you can use BrowserUtils.getLocalizedFragm<wbr>ent as<br>
a replacement. Given a document, raw string (fetch using getString /<br>
GetStringFromName instead of the "formatted" APIs), and DOM nodes to<br>
insert, it'll produce a DocumentFragment that you can<br>
appendChild/insertBefore etc., take care of splitting your strings for you,<br>
and will work with both indexed (%1$S) and non-indexed (%S) replacement<br>
points in the localized string. In the further future, I expect this type<br>
of problem will go away entirely because of Fluent.<br>
<br>
~ Gijs<br>
<br>
<br>
On 02/02/2018 07:13, Kris Maglione wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As of bug 1432966, any HTML injected into chrome-privileged documents[1]<br>
is automatically sanitized to remove any possibility of script execution.<br>
The sanitization is whitelist-based, and only allows a limited set of HTML<br>
elements and attributes. All scripts, XUL nodes, or privileged URLs will<br>
automatically be removed. This change has been uplifted all the way to 58<br>
release.<br>
<br>
If you're thinking about writing new code that injects HTML strings into<br>
chrome-privileged documents, please think again. Unless it's extremely<br>
simple, it probably won't be compatible with these changes (and will also<br>
be rejected by our default ESLint rules).<br>
<br>
Existing HTML injection in chrome documents is being gradually removed.<br>
Once that's done, the sanitization may be replaced with an outright<br>
prohibition.<br>
<br>
<br>
-Kris<br>
<br>
[1]: Using the usual HTML fragment creation methods such as `innerHTML`,<br>
`outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,<br>
notably, when using document.write().<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
<br>
</blockquote></div></div></blockquote>
<br>
</blockquote></div><br></div>