Betterbird Blog

While the Thunderbird folks are finally making their "account colour" implementation more complete in this ticket, they are discussing amongst themselves whether a colour indicator should only be added to the message list (also called thread pane) for the beloved cards view, the one that at default values wastes a lot of space, or whether it should be added to table view as well.

So one developer says to the other (quote):

Let's do this without [table view] and see how many complaints there are.

Surely user complaints are a good design principle.

Needless to say that Betterbird has shipped full account colours for both views since Betterbird 115.6.0 and even full row colour since Betterbird 115.8.0, so for more than two years. And those folks are still discussing whether a partial solution will do.

Very recently it has come to our attention that cancelling the process of sending a message via the Cancel button on the progress panel wasn't working any more after fixing the very same issue in version 115.

Unfortunately, we picked up a regression from Thunderbird 135, so Betterbird 140 was also affected. Today we shipped a fix in our "latest build 5". The Thunderbird folks are looking into getting a more comprehensive fix shipped for version 153. "More comprehensive" since this area was hit by a total of three regressions, the one affecting Betterbird 140 being the first one of the trilogy. We'll make sure it's all back to working order for Betterbird 153.

It's a bit puzzling that the failure wasn't noticed earlier. We consider being able to cancel an ongoing send operation as important feature, sometimes the last resort when a message was sent to the wrong recipients or with the wrong attachments. The Thunderbird folks pride themselves that most of their functionality is covered by automated tests, but this important feature obviously isn't.

While adjusting our fixes and features to the new Thunderbird 153 code base, we painfully come across bugs that the Thunderbird folks have abandoned and where Betterbird had to come to the rescue to offer users a decent experience. Here are some of them, and yes, we mentioned them before here and here.

Let's ask again (quoted from here): Where is the management who assigns a developer to get the issue fixed? Where is accountability?

Oops, looks like the Director, Desktop & Mobile Apps abandoned some of the bugs himself. Well, there you go!

We are busily adjusting our fixes and features to the new Thunderbird 153 code base as outlined in this article. When working on the "attachments on top" feature for both message display and compose window, we noticed that icons for certain documents are no longer displayed next to the attachment name in using the 153 code base. This also happens in other parts of the system, like here, in the Downloads Manager:

We did a bit of digging in Thunderbird's bug tracker, and lo and behold, found this ticket.

So a regression introduced in Thunderbird 141 which was shipped in July 2025, about 10 months ago. Finally, users noticed and headed to the support forum in November 2025, from where a volunteer filed the ticked we mentioned, also in November 2025. And what did the developers do? They shrugged their shoulders and left the software broken, until yesterday when two volunteers miraculously started showing some activity.

So where is QA to detect such failures before users do? Where is the management that monitors clearly visible regressions? Where is the management who assigns a developer to get the issue fixed? Where is accountability?

Ten years back, the Thunderbird project was run by some volunteers, who contributed as their personal circumstances allowed. The then chairmen of the chairman of the Thunderbird Council used to refer to the team as a "pack of cats" (although the correct term is "clowder of cats"). So with 50+ staff and millions of dollars at their disposal, what has actually changed in the attitude of those running the project?

Old and annoying 20+ year old bugs seem the be exclusively addressed by volunteers, and from them we heard questions and statements like:

• Why do [old bugs] have such little priority that I can find 20 year old low-hanging fruit?
• If I were running the shop, there would be a freeze on new internal features [...] and a systematic revision of all bug reports.

Well, good luck with 16.000+ open tickets. BTW, here is what AI had so say about so-called bug rot:

“Bug rot” is the gradual degradation of a bug tracker’s usefulness as unresolved issues accumulate faster than they are properly triaged, resolved, or retired. Over time, a large backlog—often spanning years or even decades—mixes active defects with obsolete reports, duplicates, unreproducible issues, and context that no longer matches the current codebase. This creates a system where the signal-to-noise ratio steadily worsens: important bugs are harder to identify, prioritization becomes less reliable, and contributors increasingly rely on informal knowledge rather than the tracker itself. The result is not that the project stops working, but that its issue tracker shifts from being a precise engineering tool into a partially archival, partially operational database whose meaning becomes progressively harder to interpret.

Fun fact: Paid Thunderbird staff approach those volunteers asking them to take on further bugs. That's true Mozilla exploitation culture. All those volunteers are part of the business model that counts on highly skilled people to work for free. Of course there are lots of honourable mentions, and some of them even get a free T-shirt. Our project leader used to be one of them, he still has two Mozilla T-shirts. And he usually says: Look at this T-shirt, it's worth about $50,000 of labour.

The announcement to discontinue support for Webextension Experiment add-on the monthly Thunderbird release channel starting at version 153 caused a small sh*t storm. This would affect these popular add-ons:

• ImportExportTools NG, 280k average daily users
• Provider for Google Calendar, 153k users
• LookOut (fix version), 146k users
• Send Later, 116k users
• Remove Duplicate Messages, 95k users
• Quicktext, 85k users
• Grammar and Spell Checker — LanguageTool, 73k users
• Mail Merge, 72k users
• CardBook, 62k users

Betterbird and Thunderbird ESR are not affected.

One add-on developer submitted this picture:

Read the thread for yourself here.

Today Thunderbird 153 is entering its alpha stage, also called Daily. We've started to adjust our roughly 250 patches to the new upstream code, with presently 35% done already. (Updates: 27th May 2026: 57% done, 31st May 2026: 87%).

We plan to release a Betterbird 153 beta, also called "future", when Thunderbird 153 beta is released on the 16th June 2026. Betterbird 153.0 ESR will ship around the 21st of July.

We'll see how immediately usable it will be. As a reminder, Thunderbird 102 and 128 initially shipped with backend dataloss issues, 115 had many frontend issues. These series stabilised at around dot release NNN.3.0. Let's hope that 153 will be equally quiet as 140. After all, Thunderbird has been shipping monthly releases from March 2025 (version 136), and despite those being regression-ridden, they have helped to improve the overall quality for the ESR release. Fingers crossed!

We've shipped Betterbird 140.11.0esr-bb23 today. Please refer to the Release Notes for full details.

This release contains some significant improvements.

The story started when a user alerted us to a problem with reversed threading. We fixed that and while doing so, hit a few ancient threading issues described in this bug report. Miraculously, the Thunderbird folks woke up and fixed the issue and a few related ones, so threading is a whole lot better in Betterbird 140.11.0esr-bb23. Additionally, we fulfilled a long-standing wish to be able to collapse a thread to its most recent message and not the original message. This can be enabled with the preference mailnews.collapse_thread_to_most_recent. We dedicated this blog article to the subject.

One of two further issues we fixed by popular demand was better support for internationalized domain names (IDNs), also called Umlaut domains, since in Germany they are used to include äöü in the domain name. In general, that is not recommended, since even in the year 2026 it causes a host of issues. However, with Betterbird, sending mail to such domains works correctly now. Details in this blog article.

Finally we made resetting the folder sort order of subfolders available for all folders containing subfolders, not only server root folders. It's unclear why this restriction exists in Thunderbird.

Users of (reversed) threading have always requested to show the most recent message in the thread as the collapsed root, see this Bugzilla and this GitHub report. This has now been implemented.

Note that the most recent message in a thread isn't necessarily the last displayed message in this thread:

To enable the new functionality, set preference mailnews.collapse_thread_to_most_recent. This works with and without reversed threading. Note that when this preference is set, mailnews.sort_threads_by_root has no effect, since the root and the most recent message are the same.

As a reminder, the preference to switch on reversed threading is mailnews.reversed_threading.

A preview release (lastes build 7) is available for Windows and Linux. This will ship in the next release.

This is now shipping in Betterbird 140.11.0-bb23.

Please let us know your thoughts.

Update: And of course there was an issue with cross-folder views which we fixed in 140.11.0-bb23 "latest build".

It has been brought to our attention via this Reddit post that the author of Quicktext is blocking use in Betterbird in the future via this commit. The add-on code now checks explicitly for use of the add-on in Thunderbird. This will become effective from add-on version 6.7.

We'll leave it to the assessment of the reader, whether this was done in the best spirit of collaboration in the open source world.

The mentioned Reddit article suggests the use of Clippings for Thunderbird. We tried it, it works.

We know that Quicktext is heavily integrated into some people's workflow, so unless the add-on author drops his stance, we will consider forking the add-on just to adjust the unnecessary checks for Betterbird. That new version would need to be published with a different add-on ID, so it doesn't automatically update to new versions of the original. We would also have to remove the donation facility to the original author and will likely make the forked^*) add-on only available to supporters of Betterbird.

John, please reconsider your position! Have you forgotten your comment, when our ThunderHTMLedit add-on wasn't 100% compatible with Thunderbird for a short period due to technical reasons:

From this day on, the add-on ecosystem for Thunderbird and Betterbird is not the same anymore. There are now cases were add-ons work in Betterbird, but not in Thunderbird. That was not our choice. [...] But it is unlikely that the [ThunderHTMLedit] author is going to release an update, since he does not support Thunderbird anymore.

Of course we fixed the add-on for both Betterbird and Thunderbird. Now, who's going ahead and making his add-on deliberately incompatible?

Update 1: Open source collaboration continues (NOT!) by preventing us from forking the add-on: We were also banned from filing issues or adding comments the the Quicktext GitHub repository.

Update 2: We've now published the latest Quicktext version (which has a bug in the menu on the compose window) here on our website.

Update 3: The Quicktext author reverted the change that made his add-on incompatible. This is available on GitHub as 6.7.2.

Thunderbird still hasn't implemented proper support for internationalized domain names (IDNs) as these two bugs show: Bug 235312 from 2004, Bug 923043 from 2013.

In brief, sending messages to mail addresses at internationalized domains may fail, depending on whether the final server supports so-called SMTPUTF8 (RFC 6531). If it doesn't, it likely also doesn't support UTF-8 headers (RFC 6532), and delivery will fail due to raw UTF-8 in addressing headers. This especially applies to domains hosted at IONOS.

Mail clients like Microsoft Outlook and FairEmail handle the situation somewhat better, since they unconditionally force internationalized addressing headers to ASCII-Compatible Encoding (ACE), which uses Punycode as encoding.

Betterbird has now introduced the preference mail.strictly_ace (similar to mail.strictly_mime which avoids 8bit characters in mail bodies). With this preference set, Betterbird will behave like the two mentioned mail clients and force addressing headers to ACE.

Further reading:

• IDNs
• Punycode