Thunderbird and Addons

Blake Winton bwinton at
Wed Aug 26 17:48:51 UTC 2015

On Aug 26, 2015, at 11:48, Axel Grude <axel.grude at> wrote:
> A couple of questions from my perspective as author of heavily "chrome-layer"-dependent Tb extensions:
> Could we design a survey for Thunderbird Addons authors to ask them what kind of objects they use? 

We could, but it would be at least two levels away from actually influencing what happens.
(It would be more helpful to suggest on <> that Mozilla makes a survey, since then they would get all the add-on authors, instead of just Thunderbird’s.  Also, the people writing the new API are looking at the most used extensions already, and working with many of their authors to make sure they can still work under the new system.)

> Also does moving away from XPCOM also include a restriction of accessing global variables?

Firefox/Thunderbird global variables?  Yes.  (Because you couldn't get to the browser/XulWindow object to get at them.)

> Finally for me the reliance on XUL to modify the "main" user interface (outside of content tabs) is a vitally important requirement,

Then you're going to be disappointed in Firefox, because they're moving most of their UI to HTML, so any XUL you're writing for them will break.  Which is part of why they're investing in a new API.  ;)  Fortunately, the new API is still being designed, so if there are specific things you want to do, now would be a good time to mention them!

> I wonder how Firefox deals with this? Moving its complete UI into Content Tabs, like seen in Chrome feels like a lazy hack. Certain things like modeless floating windows are impossible to achieve (or maybe not anymore?). Are there some specialists on the list who are up to date with the current API in Firefox? Can it be reused in Thunderbird?

I guess I'm probably the closest thing to a specialist in the new API here.  It isn't being designed to work with Thunderbird, and I'm not even sure they would accept patches that got it working with Thunderbird, since it's attempting to mostly mirror Chrome's API <>.  Most of the objects and functions are web-browser based, but there are ones for creating a few types of UI (Buttons, Panels, stuff like that).

I guess where I'm coming from is that we never really got Jetpack working in Thunderbird, and Thunderbird's importance to Mozilla has only declined since then, so the chances of getting this new API working are even smaller.  I don't know what our plans are to move off of or take over maintainership of XUL, but I'm thinking that we should probably think really hard about which of those we want to attempt, and if possible hire some staff to implement our decision, because I'm truly worried about the future of Thunderbird.

Sorry to be the bearer of bad news, and please don't shoot the messenger.


> thanks
>   Axel
> -- 
> Axel Grude <mailto:axel.grude at> 
> Software Developer 
> Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate4) 
> AMO Editor <Mail Attachment.png>
>> Subject: Re: Thunderbird and Addons
>> To: R Kent James, Tb-planning 
>> From: Philipp Kewisch
>> Sent: Monday, 24/08/2015 20:48:43 20:48 GMT ST +0100 [Week 34]
>> While in the short run I'd agree to all three points you mention, I think we need to plan on how we will interact with the new addon plans of Mozilla. If we go with this statement now and only make changes when core Mozilla code no longer supports it, it will be way too late to transition Thunderbird addons then and we will have an even bigger problem.
>> I do think that we should try to make the most out of what they are doing with Web Extensions and System Extensions. If this is what it is going to be, then we'll need to provide a set of APIs that Thunderbird addons can use, based on what our addons are currently doing. I've added two ideas to the uservoice page [1] [2] (plus my comment on [3]) that would benefit Thunderbird, if you have a moment please vote :)
>> It is a bit to early to make concrete suggestions on what a such API will look like since I am still unsure how they plan to replace the xul overlaying which we make more extensive use of. Working on this API early doesn't mean we can't keep xul based addons enabled longer than Firefox, but if we have to shut this done from one day to another our addon community will probably be nonexistent.
>> It is also a premier opportunity to work with the addons folks so that WebExtensions doesn't turn into a second Addon-SDK that doesn't work well for Thunderbird.
>> Philipp
>> [1] <>
>> [2] <>
>> [3] <>
>> On 8/24/15 8:35 PM, R Kent James wrote:
>>> We need to do some sort of announcement in the Thunderbird blog about our plans concerning addons. I'd like to have feedback from folks to see if there is any debate about what is the correct direction for us.
>>> We've at least agreed that we are continuing to support binary addons. Concerning signing, we took steps months ago to not move forward on requiring addons to be signed, so there are no current plans to require signing. There is still some debate about that in bug 1168571. We should probably come to a firm decision and announce it. Most commenters were opposed to signing, though there were some holdouts.
>>> Then there is "The Future of Developing Firefox Add-ons - The Mozilla Blog <>" that announces the complete disabling of current XUL addons at some point in the future. Several Thunderbird community members commented on that blog post, strongly opposed to that direction.
>>> Contrast that with Firefox/Go Faster <> where there are plans to expand the use of addons in Firefox, adding so-called "system add-ons" and moving Hello to one. (This is similar to what we are doing with Lightning, which should hopefully make our Lightning integration easier in the future).
>>> At this point, I think that the prevailing viewpoint is probably the following, and I would like to announce this if possible in a blog post:
>>> 1)    Thunderbird continues to support binary addons.
>>> 2)    Thunderbird will not require addon signing.
>>> 3)    Thunderbird has no current plans to disable the use of traditional XUL/XPCOM addons in Thunderbird.
>>> This policy must be modified by the caveat "as long as core Mozilla code can be used to support it".
>>> (I might also note that initial patches are being looked at for the integration of the technology formerly know as Skinkglue into Thunderbird core, to be called JsAccount, which makes it possible to define new account types in Thunderbird using a traditional XUL/XPCOM/JavaScript addon. This will almost certainly be in our next major release).
>>> Could I have some comments or discussion on these proposed positions?
>>> I hope the Thunderbird community appreciates that diverging from Mozilla in this manner will probably mean that we will need to take over addon review from Thunderbird at some point, possibly including forking of AMO for our own use.
>>> :rkent

Blake Winton   UX Engineer
bwinton at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list