Bug 1543493 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Right now, because Fluent uses the tree sanitizer implicitly when calling `node.innerHTML = value` in DOMLocalization:

https://searchfox.org/mozilla-central/source/intl/l10n/DOMLocalization.jsm#100

and because the tree sanitizer strips out any non-HTML, non SVG, non MathML nodes:

https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/dom/base/nsTreeSanitizer.cpp#965-996

it's effectively impossible to have XUL <image> nodes in a translation.

This is annoying because html:img ones behave subtly differently (e.g. not the same support for CSS list-style-image).

Nodes that share node local names with HTML (like <label>) are OK because DOMLocalization apparently doesn't care about namespaces, inserts stuff into an HTML namespaced <template>, so they just get interpreted as HTML:label on one side and shoved into corresponding XUL <label> elements on the other side... which is sort of wrong, but oh well, it works...

<image> breaks because our HTML parser seems to magically transform it into <img> which then doesn't map onto a XUL <image> anymore because the nodenames mismatch, as per

https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/intl/l10n/DOMLocalization.jsm#217-224 .

I see 2 solutions:

1) make the sanitizer allow some XUL elements only in XUL documents (I have no appetite for it allowing XUL anywhere else, for obvious reasons), without any attributes
2) hack up the DOMLocalization code to allow the img=image mismatch

(2) is less work but liable to break, so we should probably write an automated test to ensure it works. It also feels like it acquiesces to fluent not caring about namespaces which feels like the wrong direction longer term.

(1) is scarier because the sanitizer is used for other things, but I do have a patch in hand for that change.

Opinions on what to do?
Right now, because Fluent uses the tree sanitizer implicitly when calling `node.innerHTML = value` in DOMLocalization:

https://searchfox.org/mozilla-central/source/intl/l10n/DOMLocalization.jsm#100

and because the tree sanitizer strips out any non-HTML, non SVG, non MathML nodes:

https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/dom/base/nsTreeSanitizer.cpp#965-996

it's effectively impossible to have XUL <image> nodes in a translation.

This is annoying because html:img ones behave subtly differently (e.g. not the same support for CSS list-style-image).

Nodes that share node local names with HTML (like <label>) are OK because DOMLocalization apparently doesn't care about namespaces, inserts stuff into an HTML namespaced <template>, so they just get interpreted as HTML:label on one side and shoved into corresponding XUL <label> elements on the other side... which is sort of wrong, but oh well, it works...

<image> breaks because our HTML parser seems to magically transform it into <img> which then doesn't map onto a XUL <image> anymore because the nodenames mismatch, as per

https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/intl/l10n/DOMLocalization.jsm#217-224 .

I see 2 solutions:

1) make the sanitizer allow some XUL elements only in XUL documents (I have no appetite for it allowing XUL anywhere else, for obvious reasons), without any attributes (except the always-allowed _underscore, aria-* and data-* ones)
2) hack up the DOMLocalization code to allow the img=image mismatch

(2) is less work but liable to break, so we should probably write an automated test to ensure it works. It also feels like it acquiesces to fluent not caring about namespaces which feels like the wrong direction longer term.

(1) is scarier because the sanitizer is used for other things, but I do have a patch in hand for that change.

Opinions on what to do?

Back to Bug 1543493 Comment 0