UPDATE: 78 just repeated history with another unwelcome surprise update.
I’ve come to some peace with 68 as most of the really critical plugins were updated. But 78 is a long way from there and TB devs have continued to create some really bad blood with add-on developers. I’d argue that the strategy being taken by the devs toward compatibility is defensible, but they seem deaf to the empty wasteland they’ve made of the add-on marketplace. For me, one of the critical deficiencies is losing the support of the Enigmail developers (curiously, this 2019 post seems to be a bit behind release 2.2.4.1, which apparently adds support (!).)
A key issue is that many add-ons require hooks into the base code to be able to do things like add menus or interact with users and most of these were terminated. There is a mechanism by which tentative experimental access to many (but not all) of the previously available hooks can still be connected, but taking advantage of that experimental access still imposes a burden of rewriting, refactoring, and retesting – and then recovering user trust. All for a provisional access status that the TB devs helpful advise developers they should beg and plead to make core lest it be capriciously disabled at any future update. Understandably, those devs who stuck with TB through several major revisions of the add-on architecture and suffered reputational and time cost because of them, perceive this “convince us you’re worthy and we may grant a permanent reprieve to your code should we consider it not utterly beneath our notice” attitude as off putting.
(This is now a bit obsolete, referencing the last screw-ya’ll update that was pushed out without notice or option, it is clearly too much to hope that TB devs stop being so sure that “if you don’t do email our way, you’re doing it wrong.”)
TL:DR
If you’ve customized TB with plugins you care about, DO NOT UPDATE to 68 until you verify that every plugin you use is compatible. TB will NOT check for you and once you launch 68, the plugins that have been updated to 68 compatibility will not work with 60.x, which means you better have a backup of your .thunderbird profile folder or you’re going to be filled with seething rage and you’ll have to undo the update. This misery is the consequence of Mozilla having failed to fully uphold their obligation to the user and developer communities that rely on and have enhanced the tools they control.
BTW: if you’re using Firefox and miss the plugins that made it more than just a crappy clone of Chrome, Waterfox is great and actually respects users and community developers. Give it a try.
Avoid Thunderbird 68 Hell
To avoid this problem now and in the future, you have to disable automatic updates. In Thunderbird: Edit->Preferences->Advanced->General-[Config Editor…]->app.update.auto=False, app.update.enabled=False.
On Linux, you should also disable OS Updates using Synaptic: select installed thunderbird 60.x and then from the menu bar Package->Lock Version.
If you’ve been surprise updated to the catastrophically incompatible developer vanity project and massive middle finger to the plugin developer community which is 68 (and 60 to a lesser extent), then you have to revert. This sucks as 60.x isn’t in the repos.
Undo Thunderbird 68 Hell
First, do not run 68. Ever. Don’t. It will cause absolute chaos with your plugins. First it showed most incompatible, then updated some, then showed others compatible, but had deleted the .xpi files so they weren’t in the .thunderbird folder any more, despite being listed and shown incorrectly as compatible. This broke some things I could live without like Extra Format Buttons, but others I really needed like Dorando Keyconfig and Sieve. Mozilla’s attitude appears to be “if you’re using software differently than we think you should, you’re doing it wrong.”
The first step before breaking things even more is to backup your .thunderbird directory. You can find the location from Help->Troubleshooting Information->Application Basics->Profile Directory. Just click [Open Directory]. Make a backup copy of this directory before doing anything else if you don’t already have one, in linux a command might be:
tar -jcvf thunderbird_profile_backup.tar.bz2 .thunderbird
If you’re running Windows, old installers of TB are available here.
In Linux, using a terminal, see what versions are available in your distro:
apt-cache show thunderbird
I see only 1:68.2.1+build1-0ubuntu0.18.04.1 and 1:52.7.0+build1-0ubuntu1. Oh well, neither is what I want. While in the terminal uninstall Thunderbird 68
sudo apt-get remove thunderbird
As my distro, Mint 19.2, only has 68.x and 52.x in the apt cache, I searched to find a .deb file of a recent version. I couldn’t find the last plugin compatible version, 60.9.0 as an easy to install .deb (though it is available for manual install from Ubuntu) so I am running 60.8.0, which works. One could download the executable file of 60.9.1 .and put it somewhere (/opt, say) and then update start scripts to execute that location.
I found the .deb file of 60.8.0 at this helpful historical repository of Mozilla installers. Generally the GUI will auto-install on execution of the download. But don’t launch it until you restore your pre-68 .thunderbird profile directory or it will autocreate profile files that are a huge annoyance. If you don’t have a pre-68 profile, you will probably have to hunt down pre-68 compatible versions of all of your plugins, though I didn’t note any catastrophic profile incompatibilities (YMMV).
Good luck. Mozilla just stole a day of your life.
Mozilla Is Doing It Wrong
In the last 5 years or so, the Mozilla foundation’s software development model has drifted away from my preferred prioritization of obligation, which generally goes something like:
- Fix security flaws
- Fix upstream induced incompatibilities
- Preserve and protect existing use models
- Add features if genuinely helpful or necessary
- If there’s a new operational paradigm, branch.
No subordinate obligation should ever superseded a superior obligation—if fixing a security flaw (1) necessitates changing some frequently used feature (3), so be it. But never, ever, add a “feature” (4) that breaks an existing use mode or defined interface (3).
The issue is that there is an intrinsic trust model in open source. If a team releases a tool and people adopt it, the presumption is that the tool will continue to be usable in the same manner going forward. Everyone understand FOSS projects can stall or fail, but for the most part, they prioritize supporting the users and dependent developers why rely on them. Good examples of this model are, say, Python, which broke a lot of compatibility between Python2 and Python3. The dev team followed rule 5: branch. There’s some hassle in keeping 2.7 and 3.6 updated, they’re almost identical but not entirely compatible languages, but it preserves the investment developers made in good faith in Python2 while introducing new paradigms in Python3. Both have been maintained since 2008, going on more than a decade.
But some developers have failed to preserve that relationship of trust and the one that irks me the most is Mozilla, particularly Firefox and Thunderbird. This failure of responsibility is manifest in two areas, one superficial and one critical. The superficial aspect has been an ongoing modification of the UI/UX; for example, by default removing the toolbar and making other idiotic developer vanity modifications which I can only imagine are purely to justify the job slots of the UI/UX team. However, most of these UI/UX failures are revertible either directly or through… plugins. Which brings us to the critical failure.
First the Firefox team, and then the Thunderbird team, decided that their plugin model needed an update and, further, that they would not support the old plugin model (XPCOM/XUL). While I understand the reasons for the new API, depreciating XPCOM/XUL violated the third rule, inexcusably and unnecessarily. They could have taken one of two acceptable paths:
Fork: like Waterfox did recently with “classic” and “new” versions, they could have forked, but to do this right (as Waterfox did) you have to inform users BEFORE screwing up their installs and costing them days or months. Or, better, make the new version a whole different project name, as the mobile team at Mozilla did (yay) with Firefox Focus.
Deprecate and support: Alternatively, they could have retained support for XPCOM/XUL but disabled it by default. A few “are you sure you trust all your plugins?” questions after the update and then keep everything working. For how long? The Python2/3 life term is a good model—10 years of compatibility so far.
NextCloud, a DropBox-like “Blue Sky” (cloud-free, meaning your data lives on your hardware and isn’t gifted to some data mining corporation like Google) application is considering a similar break by changing the whole operational paradigm from synced folders to virtual drive. Why it has to be one or the other isn’t clear and the user community is vociferously disagreeing (189 comments so far) with such a poorly considered and community spiteful change. The last comment indicates some hope they’re listening, unlike Mozilla.
It’s not just me:
Some choice quotes from the plugin developer community, some of whom gave up on the 52->60 kick in the nuts and others held on for the bonus nutshot of 60->68:
https://freeshell.de/~kaosmos/index-en.html
As is well known, Mozilla has chosen to renounce XUL/XPCOM based technology for extensions and has decided to replace it with Webextensions.
For non-experts, this means that extensions now use a completely different technology and that all “old style” extensions must be rewritten from scratch to work.
Not having enough time and motivation for such a complicated job, as well as for personal reasons, I decided to completely end the development and support of all my extensions.
https://github.com/Aris-t2/CustomizeMyBird
Thunderbird 68+
CMB will not be updated for Thunderbird 68+, please don’t ask for it. I’m done with Mozilla and their lies about keeping the “old” add-on eco system in Thunderbird. This add-on will not be rewritten by me again! Use CustomCSSforTb instead
But just to put a nice pointy stick right in the eyes of their entire developer and user community, on the Thunderbird dev team page about plugin compatibility issues they say:
Even though it is possible to have both
install.rdfandmanifest.jsonfiles in your extension, so you could release a version compatible with Thunderbird 60 and 68, it is not suggested for the following reasons:
The amount of changes is huge and some changes are incompatible with Thunderbird 60 so it will require extra steps to ensure the modified version still runs with Thunderbird 60.
You may actually break your add-on for Thunderbird 60 users by releasing a backward compatible version for Thunderbird 68 (“Do not fix something, that is not broken”).
We think the time and resources needed to code and test backward compatible add-ons is not justified by the small amount of users running older versions of Thunderbird.
wow…
If you stick with 60 or 52, keep an eye on security announcements, some exploit might be found and could put a system at risk without patches. The only way to get those might be by destroying your workflow. Unfortunately, Waterfox doesn’t seem to have jumped in to create “Waterbird” yet. I had been making a monthly contribution to the Mozilla foundation, I just switched the recipient to Waterfox.
[…] repeats itself as the TB devs learn nothing from the misery they created by auto-updating 60x users to 68 without providing any warning or option to avoid the update. This is crappy user management. On […]