MailExtensions API

Ben Bucksch ben.bucksch at
Tue Jun 5 11:49:49 UTC 2018

Hello TB Council,

I had asked quite a while ago whether I could be hired to work on the 
architectural foundations of the Thunderbird future. In the Council, 
with feedback from other Council members, we had together decided to use 
the address book as test bed. That would allow to iron out the framework 
details on how to implement the foundation, from how backend modules are 
loaded (JSM, or require(), or ES6 modules, or Electron modules, or what 
have you) and backend<->frontend communication (given that each window 
might run in its own process, and we need shared data, that's far from 
trivial), over XUL overlay replacements, to localization and to widget 
sets. Now, a new topic just came up:

Firefox 45 killing bootstrapped/restartless addons. That kills pretty 
much all of our existing extensions. We have to decide how to proceed. 
Either we maintain the addon manager code to keep them alive, or we 
create a MailExtensions API. The latter is not at all trivial, it's a 
completely new architecture.

I would like to propose to design such a MailExtensions API. I would 
take somelike STEEL, at least this level of abstraction in the API. 
Then, make a similar (not identical) API as part of the WebExtensions 
API. This would allow to implement some functions in Thunderbird.

An open question is how such extensions can hook up in the Thunderbird 
UI. The problem is much harder than in the browser. In the browser, you 
only have toolbar icons, and that's it. In Thunderbird extensions, we 
want toolbar buttons, but also mail header UI, and maybe a (single) 
place to add menu items. Still, extensions need to add new mail account 
types, implement content decoding for PGP, new UI like gmail-style 
"Conversations". I personally depend on an extension for my phone 
provider that adds a button next to each phone number in the address 
book and lets me call the person with one click. How to continue to 
support all that kind of UI hookup needs to be worked out. I could 
imagine that we define certain data types, like "mail window", "folder", 
"message header", and "address contact" or "phone number", and the 
extension can add a little UI there, e.g. a button with icon, or a text. 
Thunderbird would then be able to place this UI itself, not the 
extension choosing the exact place. The list of UI places available 
would be relatively small, maybe 10 or 20. The extension UI would then 
get a reference to the object next to which it is placed, so that it can 
operate on that data, e.g. call that phone number. In other words, we 
invert the control: The extension says "I want to add something to phone 
numbers", and Thunderbird places the extension UI, and gives a reference 
to the contact and phone number, instead of the extension picking the 
exact UI place and picking the data from some internal Thunderbird 
window data structures.

Exposing some high level data APIs, like accounts, folders, messages, 
and allowing to add account types and content handlers, as well add 
exposing a certain number of UI hookup places, all with a well-defined 
API, would dramatically reduce the API surface that Thunderbird exposes, 
and allow extensions to continue to work even in face of drastic chances 
in Thunderbird.

In fact, if the extension API is done well enough and abstract enough, 
it might be possible to even let a completely new re-implementation of 
Thunderbird based on HTML be able to support the same extensions, with 
minimal or no changes, similar to how Firefox supported some Chrome 
WebExtensions. However, in order to achieve that, the API needs to be 
abstract enough and well thought out.

I am proposing to attempt that. However, it's a big project, and I would 
need to be hired for that.


More information about the tb-planning mailing list