MailExtension API support

[wshanks]

It would be nice to have access to the MailExtension API for eval commands. Perhaps an equivalent of cmd: could be created as well for MailExtension functions.

[morat523035]

We can already access the MailExtensions world from chrome.

Here is how to run the browser.tabs.create method using the console.

http://forums.mozillazine.org/viewtopic.php?p=14865767#p14865767

I'm not sure how useful something like Foxy Gestures user scripts would be.

http://addons.mozilla.org/firefox/addon/foxy-gestures http://github.com/marklieberman/foxygestures http://github.com/marklieberman/foxygestures/wiki/User-Scripts

[wshanks]

Thanks for the example! Perhaps part of it could be built into tbkeys to wrap commands, so the user only needs to put in code valid in the WebExtensions context in the tbkeys settings.

[wshanks]

I still haven't quite wrapped my head around the example code in the MozillaZine posts. It seems like it could be used to execute code using the internal API's of any installed MailExtension which is pretty powerful. I wonder if there is a good use case for supporting that (executing code in the context of another MailExtension).

In #95, I added a simpler integration with MailExtensions. It allows binding a key to an extension ID and a string and then sends that string to that extension ID using browser.runtime.sendMessage() from the background context. If other MailExtensions listen for string messages with browser.runtime.onMessageExternal() in their background context, this method can be used to send such messages. A follow up would be to send messages to content scripts if there is a use case for that.

Another similar MailExtension integration that I think would be nice is to allow specifying an extension ID and a command name to bind a key combination to trigger that extension's command with that name. This would allow binding single keys to commands where the MailExtension commands API requires a modifier key be used as well. It also allows changing the key binding if the extension does not have a built in option for doing that.

The MozillaZine example demonstrates a method for executing code in any MailExtension's context. For the restricted case of executing code using the builtin MailExtensions API's (not functions of a particular extension), I thought of another possible implementation based on what I did in #95. In #95, I created an event that the experiment code can emit when a binding is executed and that the background context can listen to. In #95, I used this to send the extension ID and message string to the background so it could call browser.runtime.sendMessage() using them. A similar event could be set up to send a string of Javascript code to be passed to eval() in the background context.

This would allow for key bindings like the current eval commands but in the MailExtension background context rather than the main Thunderbird process context. So things like browser.messages.delete() could be bound if one wanted to use the MailExtension API's rather than the internal ones (without trying to cram the MozillaZine example into a current eval command). A problem with the MailExtension API's is that they are pretty verbose. Instead of just cmd:cmd_delete, one would have to put in code like browser.mailTabs.getSelectedMessages().then((msgList) => {msgList.messages.forEach((msg) => {browser.messages.delete(msg.id)})}). Also, one issue with this approach -- tbkeys would need to specify in manifest.json any permission that someone might want to make use of from the MailExtensions API in a MailExtension eval command binding.

[morat523035]

Another similar MailExtension integration that I think would be nice is to allow specifying an extension ID and a command name to bind a key combination to trigger that extension's command with that name.

Here is my solution.

http://forums.mozillazine.org/viewtopic.php?p=14922347#p14922347

[wshanks]

Nice! I wonder if ATN would accept that code in tbkeys. They might not like the addActiveTabPermission call. The browser action version seems safe. Perhaps that should be a built in binding type for tbkeys.