Thunderbird hates addons

heritage of mozilla

with every major update you have to brace yourself for another addon becoming incompatible

why is this? it’s the arrogance of developers. they know what’s best, and what is best is their ideas, and sacrifice is worth it if only their ideas are being realized.

this is not what people started to love mozilla for, it’s the opposite. people prefer mozilla for the freedom the software gave them. but the freedom is taken away and replaced with captivity. undesirable changes are being forced upon the user and changes the user made to the software is being perceived as an attack on the power of the developers.

it’s a battle over control of the software, a battle against freedom.


I am speaking here as a user of Thunderbird since the late aughts and a maintainer of one of the most popular Thunderbird add-ons, Send Later, for over a decade.

Your characterization of why Thunderbird has taken the development path that it has is almost entirely inaccurate.

Thunderbird is inextricably tied to the Firefox codebase and the resources to sever that link simply do not exist. As such, when Firefox decides to go in a particular architectural direction, Thunderbird has no choice but to follow. The new extension architecture, which required significant porting work for extensions, is one example of this.

In addition, Thunderbird is saddled with a significant amount of technical debt, and there’s no getting around the fact that debt like that in a codebase eventually needs to be paid or the code becomes unmaintainable and unsustainable. The Thunderbird Supernova respin, which also required some porting work for extensions, is an example of necessary debt repayment.

Not only have these changes have made Thunderbird better, they’ve also made extension maintainers’ lives easier. It is easier nowadays to develop extensions for Thunderbird than it has ever been, and the work that the Thunderbird team continues to do building a robust extension API will make it even easier in the future.

Are there egos involved? Yes. Have there been some missteps in Thunderbird’s past? Also yes (for example, I personally believe that integrating chat into Thunderbird was always and will always be a bad idea and a waste of effort). This does not change the fact that Thunderbird is better now than it was in the past and continues to improve.

Your rhetoric about “freedom” and “captivity” are completely over-the-top and silly.

If you think you can do better than the team that maintains Thunderbird, you’re welcome to fork it and create your own version, as Jörg did (

1 Like

thanks for your opinion

better from a developers perspective, but better from a users perspective? a user is always fine with the status quo. or else they wouldn’t be a user. a programmer is never fine with the status quo. or else they wouldn’t be a programmer. programmers are gonna program, it’s what they do, and they will never stop, at least not when they’re paid to continue.

it’s not the first time developers decide to remove features to make the program better in their minds contrary to the users for those features. I mean it’s the same shit as Firefoxes great addon purge (xul to webext) again apparently. The funny thing is they broke this addon before at TB78 and now they break it again, removing some addon API or whatever. And the saddest part is that the addon provides an absolutely basic feature to an e-mail client: showing the e-mail address of the the sender of an e-mail.

1 Like

This reasoning is specious for two reasons.

The first, which should be obvious from the fact that people complain all the time about the software they use every day, is that it’s ludicrous to assert that a user wouldn’t use a particular piece of software unless they’re “fine” with it. They use it because it’s the best option available given the circumstances. I could talk your ear off all day about the various pieces of software I use that I’m not “fine” with but either there are no alternatives or all the alternatives are worse.

And the second reason your argument is specious is because even things that are fine can sometimes be better. Fine doesn’t mean perfect.

it’s not the XUL to WebExt transition again, it’s the same transition, just still in progress. As I said above, it’s objective fact that Thunderbird’s code base is linked to Firefox’s and when Firefox makes a big architectural change Thunderbird has no choice but to tag along, because separating that dependency would involve either (a) the Thunderbird team forking Firefox and taking on the burden of maintaining a divergent copy of the entire Firefox tree, which they don’t have nearly the resources to do, or (b) the Thunderbird team completely rewriting Thunderbird which again, they don’t have nearly the resources to do.

The transition of Firefox from XUL, and by extension the same transition in Thunderbird, benefits end users because it’s more secure, it enables add-ons to be be developed more quickly and to maintain compatibility better between releases (yes, this is true despite your complains here; there is some turbulence during the transition but as the turbulence settles down add-ons will absolutely be more portable between releases), and it enables add-ons developers to share almost all of their code between Firefox and Chrome-based browsers and any other browsers that support the WebExtension framework, making add-ons available to more people on more browsers and making it easier for users to switch between browsers without losing the add-ons they like.

If you don’t believe me that these changes make add-ons more portable between app releases, just take a look at how many Firefox or Chrome add-ons suddenly stop working when a new version of Firefox or Chrome is released. The answer is almost none of them, and the reason for that is because unlike Thunderbird add-ons, Firefox and Chrome add-ons aren’t allowed to use experiments, they’re only allowed to use supported add-on APIs, and the Firefox and Chrome teams ensure that those APIs remain stable between releases. That’s the goal that the Thunderbird team is working toward, and it’s taking them longer because they are much smaller than the team that works on either Firefox or Chrome.

Continued development of applications once they’re “fine” is also good for users, because computers and how we use them are not static, and as computers and how we use them evolves the software that we use on them also needs to evolve. Or would you rather be reading your email on a VT100?

If the Thunderbird team had infinite resources and if they weren’t time-boxed by the pace of Firefox changes then they would have had the luxury of building all necessary add-on APIs before releasing new Thunderbird versions. Unfortunately, however, they only have a few people and they have no choice but to release in lockstep with Firefox.

Because of that, during this transition period some add-ons get broken on Thunderbird upgrades. The Thunderbird team is well aware of which add-on functionality currently can’t be implemented in TB115, and they’re working on building the necessary APIs to restore it. Once those APIs are built, the add-ons that use them will be stable and much more likely to remain compatible between Thunderbird releases.

1 Like

ok excuse my ignorance, but wasn’t the great transition that first, they broke everything (it was definitely the case at Firefox, did that coincide with the TB breakage?) and then they would successively restore APIs. So my bewilderment stems from the fact that this is still going the other direction, stuff being broken/removed instead of restored.

The point of building stable APIs that add-ons talk to is so that you can change the stuff under the hood inside the application without breaking the add-ons. As long as you maintain the API interface, the add-ons keep working even if there are tons of changes they can’t see.

However, there is a ton of functionality that all the Thunderbird add-ons need to be able to do what they do, and the Thunderbird team wasn’t large enough to build all the APIs at once, so they’re implementing them gradually over time, prioritizing the ones that are required by the most / most popular add-ons. In the meantime, other add-ons, which need APIs that aren’t built yet, need to keep messing around inside Thunderbird’s internals, i.e., the unstable stuff. This is what causes some add-ons to break when there are new Thunderbird releases: Thunderbird needs to change something in a part of the code that isn’t supported by an API yet, and the add-on code that works directly with that internal Thunderbird code stops working as a result.

As more add-on APIs are built and stabilized in Thunderbird this will happen less often. The aspirational goal is for the APIs to be sufficient that none of the add-ons will ever have to talk directly to internal Thunderbird code. I’m honestly not sure that’s achievable, but we can get a lot closer than we are now, and therefore get to a point where a lot fewer add-ons break when new TB versions are released.

1 Like

Es ist tatsächlich zum Kotzen! Nostalgy++ ist für mich DER Grund, Thunderbird zu nutzen. Und jetzt zum zweiten Mal: Eine neue Version von Thunderbird und Nostalgy++ funktioniert nicht mehr. Es ist schlimm genug, daß bei neuen Programmversionen so häufig das graphische Erscheinungsbild geändert wird.

The developer is working on an update.
He wrote: " A test version for TB 115 is at"