Allow UA Widget to use Fluent
Categories
(Core :: Internationalization, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox65 | --- | affected |
People
(Reporter: timdream, Unassigned)
References
(Blocks 1 open bug)
Details
Currently, UA Widgets reuses the DTDs that gets included when we parse XBL. https://searchfox.org/mozilla-central/rev/50ba1dd30cf013bddce1ae756f1b3c95b26f0628/toolkit/content/widgets/videocontrols.js#2195-2199 It achieves that by having its markup ran through DOMParser (and also leverage the fact that we all any web content to access resource DTDs). UA Widgets ( https://firefox-source-docs.mozilla.org/toolkit/content/toolkit_widgets/ua_widget.html ) are special JS + Shadow DOM dropped to the web content document. The JS holds expanded principal so it's possible to give them access to APIs unavailable to web content. We'll need some setup to enable UA Widgets to get the strings from the browser, without disrupting the content document (e.g. put the strings to a place accessible to the web content or deny its ability to use Fluent independently) Perhaps Fluent can localize the Shadow DOM without walking into the document DOM? Perhaps through some gatekeeping via WebIDL UA Widgets can access Fluent and string resources without letting web content to do the same? This is not a hard blocker to UA Widgets or de-XBL effort. I am filing this bug so I can include this in the datetimebox.js patch.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 2•5 years ago
|
||
No. I can see videocontrols.js still uses DTDs.
|
|
||
Comment 3•5 years ago
|
||
Well, I guess the question is "could they do it, and if so how" and not so much if they already do.
We have everything we need to localize shadow DOM, we do that extensively now. So the question boils down to where in ua widgets we have something with access to the DOMLocalization class?
Is this just picking one of those widgets and see if it works?
|
||
Comment 4•5 years ago
|
||
I took a look at this and it seems to me that what we want here is ability to generate custom DOMLocalization instances and for that to happen we need to expose DOMLocalization.webidl to IsChromeOrXBLOrUAWidget.
For that to happen, we'd need to move DOMLocalization.webidl from dom/chrome-webidl to dom/webidl.
Once we have this, one could:
- In https://searchfox.org/mozilla-central/rev/8a63fc190b39ed6951abb4aef4a56487a43962bc/toolkit/content/widgets/videocontrols.js#2549
- Create a new DOMLocalization instance
- Attach the shadowRoot of the fragment to that instance
This would provide full localization of the fragment using DOMLocalization.
Olli - does it sound reasonable to you? Should we move this class (and maybe Localization.webidl) to expose it to UA Widgets?
|
||
Comment 5•5 years ago
|
||
So which localization file would be used? Would it use <link> somehow?
|
|
||
Comment 6•5 years ago
|
||
My thinking was to do this imperatively:
let domLoc = new DOMLocalization(["browser/menubar.ftl", "branding/brand.ftl"]);
const parser = new this.window.DOMParser();
let parserDoc = parser.parseFromString(
"<span data-l10n-id="key1"/>"
);
this.shadowRoot.importNodeAndAppendChildAt(
this.shadowRoot,
parserDoc.documentElement,
true
);
domLoc.connectRoot(parserDoc.documentElement);
|
||
Comment 7•4 years ago
|
||
I am unfamiliar with this area but needed this for my work on bug 1496851. Unfortunately, I missed this bug and filed bug 1659625 instead, including a patch. We could either:
- Mark this as a dup and shift the blocked bugs over;
- Mark this as depending on bug 1659625; or
- I can try to move the patch over to this bug.
|
|
||
Comment 8•4 years ago
|
||
Thank you for taking this bug. I'll mark it as depending on bug 1659625, and we can resolve this once bug 1659625 lands.
|
|
||
Comment 9•4 years ago
|
||
Bug 1659625 has landed, so we're done here. For an example of how to set things up in an actual UA widget, see https://hg.mozilla.org/mozilla-central/rev/0aa1e618b7a3 .
Description
•