browser.l18n in a webextension experiment
The browser namespace in an experiment api isn't defined, is there a way
to do this? For example rather than adding chrome menuitem and labels
using and overlay and dtd it would be better to have the experiment api
generate the elements and labels like this:
doc.getElementById("view_layout_popup").insertBefore(mainWin.MozXULElement.parseXULToFragment(`
<menuitem id="messagePaneClassic" closemenu="none" type="radio" name="viewlayoutgroup" label="${browser.i18n.getMessage('layoutClassicLabel')}" accesskey="${browser.i18n.getMessage('layoutClassicAccesskey')}" paneconfig="kStandardPaneConfig" oncommand="ChangeMailLayout(event, kStandardPaneConfig);"/> `), doc.getElementById("viewMenuAfterPaneVerticalSeparator"));This would avoid having an overlay and a dtd which will be obsolete.
Fluent doesn't look like it's ever going to support webextensions.
Clever attempts like passing |browser| or |browser.l18n| in from
background.js don't work (xray violations). It doesn't seem keeping
browser from a chrome privileged experiment makes much sense and hinders
moving away from overlays/dtd (at least for Tb).
Any ideas?
Hi alta88,
the API shouldn't be designed in a way that you rely on magic strings in browser.i18n to be present.
You can either make it a manifest entry if it will definitely only be one item (c.f. the omnibox, browserAction, pageAction apis), or an api call where you have parameters or keys of an options object (c.f. browser.tabs.create)
Philipp
On 14. Jul 2019, at 10:40 PM, alta88 alta88@fixall.com wrote:
The browser namespace in an experiment api isn't defined, is there a way to do this? For example rather than adding chrome menuitem and labels using and overlay and dtd it would be better to have the experiment api generate the elements and labels like this:
doc.getElementById("view_layout_popup").insertBefore(mainWin.MozXULElement.parseXULToFragment(`
<menuitem id="messagePaneClassic" closemenu="none" type="radio" name="viewlayoutgroup" label="${browser.i18n.getMessage('layoutClassicLabel')}" accesskey="${browser.i18n.getMessage('layoutClassicAccesskey')}" paneconfig="kStandardPaneConfig" oncommand="ChangeMailLayout(event, kStandardPaneConfig);"/> `), doc.getElementById("viewMenuAfterPaneVerticalSeparator"));This would avoid having an overlay and a dtd which will be obsolete. Fluent doesn't look like it's ever going to support webextensions.
Clever attempts like passing |browser| or |browser.l18n| in from background.js don't work (xray violations). It doesn't seem keeping browser from a chrome privileged experiment makes much sense and hinders moving away from overlays/dtd (at least for Tb).
Any ideas?
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
Thanks Philipp,
On 07/15/2019 05:47 AM, Philipp Kewisch wrote:
Hi alta88,
the API shouldn't be designed in a way that you rely on magic strings in browser.i18n to be present.
I'm not sure why browser.i18n is 'magic' or why it would be bad practice
to have it available to an experiment api function or to regular
privileged chrome code? I haven't found a way to import some jsm and get
browser in chrome code, and it seems that's intentional.
The extension is fine as an overlay with dtd and chrome.manifest. But
I'd like to get away from that and inject xul into Tb chrome with
strings gotten from _locales/../messages.json. So make it as much of a
pure webextension as possible.
You can either make it a manifest entry if it will definitely only be one item (c.f. the omnibox, browserAction, pageAction apis), or an api call where you have parameters or keys of an options object (c.f. browser.tabs.create)
Are you saying browser.l18n can be defined as a parameter in
manifest.json or the api schema.json?
I've defined my experiment api init function in a schema.json, put it in
manifest.json and it works fine from background.js at startup. Note that
it's an experiment only to get chrome privileges, not because it's going
to be an official api.
On 15. Jul 2019, at 8:45 PM, alta88 alta88@fixall.com wrote:
Thanks Philipp,
On 07/15/2019 05:47 AM, Philipp Kewisch wrote:
Hi alta88,
the API shouldn't be designed in a way that you rely on magic strings in browser.i18n to be present.
I'm not sure why browser.i18n is 'magic' or why it would be bad practice to have it available to an experiment api function or to regular privileged chrome code? I haven't found a way to import some jsm and get browser in chrome code, and it seems that's intentional.
It is certainly possible, but not at all common. I don't have the code handy, but it was some getAPI call on the extension object using the context available. Last time I tried this it was very hacky and there is a possibility of race conditions if the api isn't loaded yet, though I think I fixed that.
I haven't seen any apis that rely on a string with a certain name being present, while I have seen many that take a string argument.
I think the background is that the wx api shouldn't have any side effects and that everything should be as explicit as possible.
The extension is fine as an overlay with dtd and chrome.manifest. But I'd like to get away from that and inject xul into Tb chrome with strings gotten from _locales/../messages.json. So make it as much of a pure webextension as possible.
If you could share your schema I can advise further. Generally you'd want:
browser.myapi.addViewLayout({
label: browser.i18n.getMessage("layoutClassicLabel")
...
})
This way there is an explicit call from the extension code to add that layout, and it passes in the string from the i18n api. A more simple extension could just pass in a fixed string, not needing to set up locales.
Another thing I've seen in the browser menus api is the use of & in the layoutClassicLabel message to figure out what the access key should be.
You can either make it a manifest entry if it will definitely only be one item (c.f. the omnibox, browserAction, pageAction apis), or an api call where you have parameters or keys of an options object (c.f. browser.tabs.create)
Are you saying browser.l18n can be defined as a parameter in manifest.json or the api schema.json?
You can add some sort of preprocessor to the schema.json that says that manifest keys should have strings replaced, so you can use I think MSG_stringname. Please double check, I am on mobile. I think the cloudfile api does this, definitely the browserAction api.
I've defined my experiment api init function in a schema.json, put it in manifest.json and it works fine from background.js at startup. Note that it's an experiment only to get chrome privileges, not because it's going to be an official api.
This is exactly the kind of API I'd like to warn about. It is certainly possible to use the api just to get chrome privileges, but you will have a hard time migrating if at some point we lock down experiments to only nightly.
We have experiments open on release because we couldn't migrate on the same timeline as Firefox, but if extension authors just use the escape hatch to get chrome privileges it will just lead to more migration problems down the line.
It would be better to write the api in a way that it could be used in a more general fashion. Of course if the UI you are adding is unlikely to be accepted in core it will be difficult, but then maybr there is a way to design the UI so that it fits into the extension points available.
I of course can't stop you if you want to proceed nevertheless, but I just wanted to bring this up. Hope you understand my angle.
Philipp
On 07/15/2019 02:58 PM, Philipp Kewisch wrote:
The extension is fine as an overlay with dtd and chrome.manifest. But I'd like to get away from that and inject xul into Tb chrome with strings gotten from _locales/../messages.json. So make it as much of a pure webextension as possible.
If you could share your schema I can advise further. Generally you'd want:
browser.myapi.addViewLayout({
label: browser.i18n.getMessage("layoutClassicLabel")
...
})
This way there is an explicit call from the extension code to add that layout, and it passes in the string from the i18n api. A more simple extension could just pass in a fixed string, not needing to set up locales.
Another thing I've seen in the browser menus api is the use of & in the layoutClassicLabel message to figure out what the access key should be.
This and other comments are very helpful and I see how it can be done;
I'm just at the prototyping stage chipping away at removing dtd from
chrome.manifest and adding xul in an init function.
The browser.menus api seems only for context menus and isn't useful for
appmenu or menuitems
I've defined my experiment api init function in a schema.json, put it in manifest.json and it works fine from background.js at startup. Note that it's an experiment only to get chrome privileges, not because it's going to be an official api.
This is exactly the kind of API I'd like to warn about. It is certainly possible to use the api just to get chrome privileges, but you will have a hard time migrating if at some point we lock down experiments to only nightly.
We have experiments open on release because we couldn't migrate on the same timeline as Firefox, but if extension authors just use the escape hatch to get chrome privileges it will just lead to more migration problems down the line.
It would be better to write the api in a way that it could be used in a more general fashion. Of course if the UI you are adding is unlikely to be accepted in core it will be difficult, but then maybr there is a way to design the UI so that it fits into the extension points available.
I of course can't stop you if you want to proceed nevertheless, but I just wanted to bring this up. Hope you understand my angle.
Sure, and I don't want to go down a deprecatable path. The problem is
that this particular extension (adding additional 3pane layouts and
menuitems to change to them) isn't likely to create an api that will be
useful to (m)any other extensions. But it has to be privileged,
monkeypatch UpdateMailPaneConfig() and set properties on the messenger
object etc etc. I think there are a lot of other extensions in the same
boat using very specific internals that aren't api-worthy. It seems best
to leave it as an overlay extension, not sure what other conclusion I
can draw if abusing experiments will someday (not incorrectly
necessarily) be removed from release.