Intent to de-support: traditional add-ons

Axel Grude axel.grude at
Sat Oct 5 01:18:29 UTC 2019

I absolutely agree 100% with everything Jörg said. I think I would have somehow liked 
to express this, and that's exactly why we need a show an tell for Add-on authors, so 
show / explain to *core developers *what we do with our Add-ons. I think just relying 
on one of them discovering and using one of our Add-ons gives us only a very slim 
chance to be regarded.

Also, at the moment I would not know how to convert most of the things I do into 
APIs... I use a lot of XPCOM functionality (I think up to 50 different XPCOM 
interfaces, for some only one or two functions others absoultely deep diving), so the 
question is, *what of this can be "safely" exposed* to a web extension?

This was also one of the reasons why I thought " if it is *unsafe* for an Add-on *to 
use XPCOM* /*why is it safe for Thunderbird JavaScript core code*/?".

As a Core Developer, please ask yourself: if the Thunderbird "Scripted layer" was 
*forced *to go through an API (not allowed to use XPCOM idls anymore), would you 
/*design it differently*/?


*Axel Grude <mailto:axel.grude at>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders 
quickFilters <>, 
QuickPasswords <>, Zombie Keys 
<>, SmartTemplate⁴ 
Visit my YouTube Channel <> for email 
productivity tips Get Thunderbird!
> *Subject:*Re: Intent to de-support: traditional add-ons
> *From:*Jörg Knobloch <jorgk at>
> *To:*<tb-planning at>
> *Sent: *Thursday, 10/3/2019, 22:42 22:42 IST +0100 [Week 40]
> On 01 Oct 2019 15:02, Magnus Melin wrote:
>> As an author of a traditional add-on, what should you do? There are two routes: A) 
>> convert your add-on to a MailExtension. If the API you need doesn't exist yet, tell 
>> us about it 
>> <>.
> I think this is not the right way to go about it.
> What we should do is look at selected set of add-ons and see what they do. This is 
> not hard, since developers are also add-on authors and many add-on authors are also 
> volunteers.
> Take some examples:
> Quick Folder Move written by Philipp: Changes a context menu, the one for "Move To", 
> takes a search string in popup that pops up from the context menu, searches for 
> folders matching the string, presents a menu with the result, lets the user pick 
> one, moves the messages. Doable with today's set of APIs? If not, there's something 
> missing.
> Shrunked image resizer written by Geoff: Observes the message body and attachment 
> bucked of the compose window for images being added, offers to resize those images 
> in a notification in the status bar, resizes them and changes the item in the 
> message body or attachment bucket. IOW, it messes with the message body. Doable with 
> today's set of APIs?
> ThunderHTMLedit written by me: Adds a tab to the compose windows' body, lets switch 
> to the tab to display the HTML of the message. It doesn't need to be a tab, it could 
> be another toggle. Lets user edit the HTML in a 3rd party HTML editor, and when the 
> user switches back to the message body, replaces the body with the HTML. Doable with 
> today's set of APIs?
> Various add-ons add a custom column to the thread pane/message list. Doable with 
> today's set of APIs?
> If I spent 10 more minutes on this, I could come up with another set of "common" 
> scenarios. I'm sure, Axel could provide a list of what his complex add-ons do. I 
> don't know much about them, but they do some stuff already mentioned above. I think 
> messing with the message being composed is very common to many add-ons, like the 
> ones mentioned or QuickText or SmartTemplate.
> In summary: It's not efficient to let add-on authors discover that is needed, it's 
> more efficient to go through some common functionality and check whether it is 
> covered by APIs or not.
> Jörg.
> _______________________________________________
> 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