Ξ

My reaction to Thunderbird 78

Published on 2020-10-10 code design

Thunderbird 78 was accepted into Debian stable on Tuesday. Since then I basically worked full time on that update. First because I had to migrate PGP support from Enigmail to the new built-in mechanism and second because I had to port my own extension.

Email is probably the most important form of communication I use. A broken email setup is a big deal. Not realizing I got new mails because the UI has slightly changed is a big deal. This had to be fixed as soon as possible. My immediate reaction was: “This is more important than sleep, so wake up and work!”

I don’t want to feel like it was all for nothing, at least I want to write down what I learned. So this is me rambling about some random software release.

WebExtensions

So let’s start at the beginning. What was this release all about? If you look through the official release notes it sound like the focus was on UI improvements but honestly those changes are marginal and feel more like an instance of “change for the sake of change”. You know, the kind of change that users hate because they have to adapt to a new UI without getting anything in return.

The big change in my opinion was the removal of legacy extensions. Just as with firefox, the only way to create extensions for Thunderbird now is to use the WebExtension APIs (with major loop holes, we will come to that). This is a hard pill to swallow because it means that all extensions have to be rewritten completely, and some may not be possible with the new APIs at all. But in contrast to the UI changes described above I can see a lot of value in the refactoring work that is being done, even if it causes me some trouble.

Builtin PGP support

One of the most popular extensions that was not going to be supported was Enigmail. The Thunderbird developers of course would never dare to release a mail client without proper PGP support, so after years they finally added PGP support to Thunderbird itself. Much of that was based on the Enigmail code, but they also made some interesting changes:

They used RNP instead of GnuPG. This means that keys have to be migrated and existing tooling for key management no longer works.

Getting rid of GnuPG also means getting rid of the web of trust, which is probably a good thing. Unfortunately they replaced it with this sequence of dialogs:

To explain how terribly awful this UI is I would like to quote Wikipedia:

Warning fatigue has pushed many messaging applications to remove blocking warnings to prevent users from reverting to less secure applications that do not feature end-to-end encryption in the first place.

So this is a deal breaker for casual users, but probably bearable once you have set trust on your usual acquaintances.

On the same level of “not awful, but definitely not good either” is the compose UI:

There is a “security” button that opens a confusing dialog. Attached to that button is an overly complicated menu that actually allows you to encrypt your message. In order to see whether a message will be encrypted there is a tiny icon in the status bar, without any label or tooltip. This is wrong on every step of the way. Who designs something like that?

Luckily I found a way to change the UI: Large parts of Thunderbird are written in javascript and HTML/XML, and that code is bundled in a zip file at /usr/share/thunderbird/omni.ja. I know javascript! So messing around with that file got me to this:

You can also vote for this UI on the feature request I created.

(Full disclosure: I am not a genius designer. I just copied what enigmal had done before.)

My own extension

All that was the easy part, the part where I can simply vent about bad design without any responsibility of my own. This part now is about an extension I wrote and use that is probably unnecessary and, what is worth, is just a clone of another, well maintained extension. I got a bad case of NIH. So this one is completely on me.

My extension provides an alternative thread view. To achieve this it must contain the following parts:

Basically none of that is supported in the current WebExtension APIs. Luckily there is an escape hatch called WebExtension Experiments. It allows you to create your own APIs while utilizing all kinds of Thunderbird internals, just as in the old days.

Some of what I need is not that far away: It is already possible to get the message body and I expect that encryption support will be added some time soon. Reply and forward are already available and adding “edit as new” should just be a formality.

But other things will likely never be supported, e.g. replacing the default action when opening a message.

And then there is everything in between. Stuff that is not too far out, but probably too special interest to be included in the official APIs.

So the big question is what will happen to Experiments in the future: Is this just a temporary playground to test different interfaces until we settle on a common set? Or will it be around indefinitely to support fringe use cases?

Conclusion

This is not really about bad design because I think with all the refactoring and UI cleanup as well as the built-in PGP support Thunderbird 78 is the best version yet. This is not about bad or missing documentation because the longer I searched the more and better documentation I found. This is not about bad code because once I actually dared to look at the Thunderbird code I found it to be quite understandable.

As the days went by my frustration and anger was replaced by understanding and even motivation. I would not go as far as “excitement” but sometime on day 3 I had regained the feeling of fun while programming.

Maintaining my own extension gave me a deeper insight and appreciation for Thunderbird. And 4 days of nerve wracking stress.