Thunderbird and Addons
R Kent James
kent at caspia.com
Wed Aug 26 19:44:44 UTC 2015
We had a long discussion about addons in Thunderbird at our group
meeting yesterday. We are trying to decide what we can say about our
current policy towards addons. This thread is part of the information
gathering for that.
On binary extensions, we're pretty agreed that the policy stance is
this: We currently continue to accept binary extensions, and there are
several key binary extensions in our addon ecosystem. But they are
deprecated, mostly because with Firefox no longer accepting them, there
are likely to be breaking changes in core code that we cannot overcome.
Anyone with a binary extension needs a migration plan away from that.
It would be good to inform us of any binary extensions that are out
there and your needs. If there are core hooks needed to allow your
extension to function, we are pretty accommodating to that. Most of my
personal new development effort is going into adding addon hooks to core
for new account types, which are needed both for my own ExQuilla binary
extension, but also for the work we are doing to incorporate other new
protocols such as JMAP.
Certainly binary extensions are and will continue to be allowed in
Thunderbird 38.* For our next major version, 45.*, the picture is not
clear yet, but I would hope yes. But probably not beyond that.
The story is very similar with addon signing. That is, not required in
Thunderbird 38, not yet clear for Thunderbird 45 but probably will not
be required there, after that who knows.
We have no current plan for dealing with the XUL deprecation issue. We
don't get invited to sit at the cool kids table anymore, so this is
hitting us about the same time it is hitting you (though I suspect the
discussion was public if we had looked hard enough).
In the long run, I'm actually excited about the prospects of solving all
of the issues with HTML that would allow us to run Thunderbird as pure
HTML. That would give us the long-term hope of having a product that
could run outside of the Mozilla binary environment, such as on mobile
devices or as a pure web app. I actually think this is likely in the
long run to be more beneficial for Thunderbird than for Firefox. But the
work to get there is enormous, and we are still trying to sort that.
Concerning the effect of that on addons, whatever we do will probably
lag Firefox by about a year, and even for them I think the situation is
quite murky right now. We're just going to have to wait and see what
Firefox ends up doing to solve the extension problem, adapt it if we
can, if not we'll have to figure out something else. I realize that that
is not a particularly satisfying answer, but Mozilla does not ask our
permission before they make big public announcements like this. We're
still trying to formulate a position that we can announce officially,
even if that position just confirms our uncertainty.
At least for Thunderbird, we have no current intention of either trying
to reduce the power of addons, nor trying to be compatible with some
industry-wide standard for addons (since there is no equivalent to "Web
Extensions" for email clients). We're a different product than Firefox
with different needs. But the prospect of trying to do our own thing
here independent of Firefox would be enormously challenging.
On 8/26/2015 8:19 AM, Chris wrote:
> I work on BirdieSync software which synchronizes contacts, events, and
> possibly tasks and mails between Android, iPhone, Windows Mobile
> devices and Thunderbird. I'm concerned about the last news about the
> possible evolutions regarding add-ons. BirdieSync has a third-party
> add-on in Thunderbird which relies on XPCOM and XUL through binary
> components, and uses the needed XPCOM interfaces to access to
> contacts, calendars and mails.
> The new step of switching to another technology than XPCOM and XUL for
> add-ons would be problematic at the least. If add-ons would need to
> rely exclusively on WebExtensions API in the future, it would mean a
> huge work having to fully rewrite the add-on, and potential lacks in
> the new restricted API. For instance, the API to connect with native
> applications is only said to be "likely" offered by Mozilla and it
> would be necessary to have a new dedicated API in Thunderbird to
> manage contacts, calendars and mails, available to third-party developers.
> I hope that alternative solutions will be possible to continue
> offerring access to XPCOM components in Thunderbird, also through
> binary components. I'm aware that the decision of continuing offering
> support of XUL and XPCOM add-ons may not only depend on Thunderbird
> will and may depend on future Mozilla Core evolutions. If it couldn't
> be possible, I only hope that it would be at least feasible to achieve
> with the new API what was possible with XPCOM.
> I will take the opportunity of this mail, to thank all the Thunderbird
> team for the great job they do, their hard work and involvement !
> Le 8/24/2015 8:35 PM, R Kent James a écrit :
>> 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
>> Then there is "The Future of Developing Firefox Add-ons - The Mozilla
>> 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
>> <https://wiki.mozilla.org/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
>> 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.
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning