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
