---
title: My reaction to Thunderbird 78
date: 2020-10-10
tags: [code, design]
description: Email is probably the most important form of communication I use. A broken email setup is a big deal.
---

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][1] 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][2] (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][3]. 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][4] 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][5], which is
probably a good thing. Unfortunately they replaced it with this sequence of
dialogs:

-	![warning message telling me that something is wrong with one of the recipients](trust_1.png)
-	![list of recipients](trust_2.png)
-	![another list, this time of keys?](trust_3.png)
-	![a wordy dialog that allows me to set the trustlevel from "not sure" to "still not sure, but whatever"](trust_4.png)

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

> 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:

![](compose.png)

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. yay! 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][7]. *I know javascript!* So messing around
with that file got me to this:

![](compose_patched.png)

-	I can immediately see whether my message will be encrypted.
-	I can change it with a single click.
-	The complete set of options is still available from the menu bar.

You can also vote for this UI on the [feature request][8] 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 worse, is just a clone
of [another, well maintained extension][9]. I got a bad case of NIH. So this
one is completely on me.

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

-	Hook into the code that opens messages on double click
-	Open a new tab with my UI code
-	Pass persistent identifiers for the selected messages to that tab
-	Get all messages from the thread
-	Display each message, including its (decrypted) body
-	Support a bunch of actions like reply, forward, edit as new, view in classic
	reader, and view source

Basically none of that is supported in the current WebExtension APIs. Luckily
there is an escape hatch called [WebExtension Experiments][11]. 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.

[1]: https://www.thunderbird.net/en-US/thunderbird/78.0/whatsnew/
[2]: https://webextension-api.thunderbird.net/
[3]: https://addons.thunderbird.net/de/thunderbird/addon/enigmail/
[4]: https://www.rnpgp.com/
[5]: https://en.wikipedia.org/wiki/Web_of_trust
[6]: https://en.wikipedia.org/wiki/Trust_on_first_use
[7]: https://web.archive.org/web/20210531175757/https://developer.mozilla.org/en-US/docs/Mozilla/About_omni.ja_%28formerly_omni.jar%29
[8]: https://bugzilla.mozilla.org/show_bug.cgi?id=1669788
[9]: https://github.com/thunderbird-conversations/thunderbird-conversations
[10]: https://github.com/xi/xi-conversations
[11]: https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#webextensions-experiments