MailExtensions API

Axel Grude axel.grude at
Tue Jun 5 12:06:17 UTC 2018

Dear Ben,

on the detail of UI, thanks for starting the conversation.

There are many many many more places where Add-ons expand UI - you listing just a few 
probably shows that even you may underestimate the problem.

Let's take the account manager -Add-ons still need a way to add decks and modify 
existing ones. The Filter list - add-ons need a way to extend the search interface and 
add toolbars. The filter editor - Add-ons need a way to add new UI elements and code. 
Even if XUL is scrapped Add-on will need a way to interfere with the dialog document 
tree possibly just with DOM methods. Many Add-ons need a way to create (floating) 
dialogs that are not restricted to a single tab. If you have an Add-on that styles the 
main interface you need it's settings outside of a tab for instant feedback (because 
the change more than likely may affect the 3pane window and can't be seen while 
looking at an "options tab"). A floating dialog may also be used to things like 
correction / lookup features in mail / composer content and ideally should not be 
restricted to the window's client area. That's why I repeatedly asked about the future 
of non-modal windows (Thunderbird has plenty of these).

Also will we still be able to add custom icons to the folder tree?

just a few of my   UI thoughts...

*Axel Grude <mailto:axel.grude at>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders 
quickFilters <>, 
QuickPasswords <>, Zombie Keys 
<>, SmartTemplate4 
Visit my YouTube Channel <> for email 
productivity tips Get Thunderbird!
> *Subject:*MailExtensions API
> *From:*Ben Bucksch <ben.bucksch at>
> *To:*Tb Council; Tb-planning
> *Sent: *Tuesday, 05/06/2018 12:49:49 12:49 GMT ST +0100 [Week 23]
> 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.
> Ben
> _______________________________________________
> tb-planning mailing list
> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list