Betterbird Blog

The article picture shows the effects of two recent regressions in Thunderbird 153.0.2 (ESR).

The left part shows what happens when trying to drag a message or message attachment to the desktop or a folder: Unspecified error. This is tracked in this ticket. The breakage was caused by the Mozilla team when fixing a security issue in Firefox 155; this fix was backported to Firefox 153.0.2 and also hit Thunderbird.

The right part shows what happens when dragging an image in a compose window to a different location or another compose window: The internal representation of the image is inserted as text. This is tracked in this ticket. The breakage was caused by the Mozilla team implementing changes to drag and drop for Firefox 151 in March 2026. Here QA has completely failed, since no one detected the breakage with affects both Firefox and Thunderbird since version 151 until the end of July 2026.

To understand what has happened, let's dive into how code for Firefox, Thunderbird and Betterbird is structured.

Firefox at version 153 consists of roughly 40 million lines of code. This includes code for the Firefox frontend (tab bar, address bar, bookmarks, and other Firefox-specific UI); Firefox mobile; the SpiderMonkey JavaScript engine; the DOM implementation; the layout and graphics pipeline covering CSS style resolution; the WebRender compositor, font rendering, and image decoding; the networking stack handling HTTP, DNS, and sockets; the NSS cryptography library providing TLS and certificate handling; the media engine for audio, video, and WebRTC; the XPCOM component model, which bridges JavaScript and C++ and provides cross-platform file I/O, threading, string handling, and process management; the widget layer that abstracts native windowing, event loops, clipboard, and drag-and-drop across Windows, macOS, and Linux; internationalisation; the shared toolkit providing preferences, add-on management, password storage, printing, downloads, and other cross-application services (Places, Find-in-page, Search engines, Autocomplete, Crash reporting, Telemetry (the latter two not being used in Betterbird)); and additionally the developer tools.

Of these 40 million lines, five million lines covering the Firefox frontend and Firefox mobile, are not shared by Thunderbird/Betterbird. Thus, these programs use 35 million lines of the so-called Mozilla platform code and two million lies of code of their own. Those two million lines cover the frontend and the backend with the following functionality: IMAP, POP3, Exchange and NNTP protocol implementations; the message database layer (including the legacy Mork format, the newer Gloda global-message-database and the future Panorama database); MIME parsing; message composition including HTML editing; the address book with LDAP and CardDAV; OpenPGP and S/MIME encryption; mail import/export; also included are Calendar (local calendars, CalDAV, invitations and scheduling, import/export) and Chat (IRC, XMPP, (defective) Matrix).

As mentioned above, the two regressions were caused by changes in the Mozilla platform code which is geared mostly towards Firefox. There was little chance to catch the first one since it was implemented for Firefox 155 at the end of July 2026, and was integrated into earlier branches, like the 153 release and ESR branches, almost immediately. Of course, an automated test would have caught it straight away, but despite touting their test suite, the Thunderbird test suite has many holes, also for very important functionality. There were more than four months to detect the second issue, but it went undetected until very recently.

Betterbird 153.0esr users are not affected by the first issues and we have published 153.0esr "build 7" with a fix for the second issue, well ahead of Thunderbird.

In general, at Betterbird, we patch both the Mozilla and the Thunderbird codebase, whereas the Thunderbird folks only manage their own code and rely on Mozilla staff for backporting fixes in the Mozilla platform code. This leads to delays in fixing bugs in the ESR version of up to one year.

When the Betterbird CEO was still in charge of Thunderbird releases until 2019, Thunderbird didn't rely completely on Mozilla staff for backports, it could independently fix bugs in the ESR version. These days, the Thunderbird folks either don't care or lost the ability.

It's been more than a month that we talked about regressions on the Thunderbird release channel in this article. So here is the next installment.

Careless refactoring in this bug caused a total of four regressions.

One of them, reported in bug 2040638, has clocked up 18 duplicates from affected users. The symptoms revolved around messages with attachments which caused failures when sending a or saving as draft. The second issue reported as bug 2050589 manifested itself in a stuck progress window, see article image.

Both bugs were fixed by Thunderbird's new star volunteer contributor while full time employees turned a blind eye or are enjoying their well-earned holidays. Needless to say that release channel users are still suffering as Thunderbird release management has not made the fixes available on this channel. Even on beta 153, only one of them was shipped. Both fixes are of course included in Betterbird's beta release.

We've lamented the squanderous allocation of Thunderbird resources before, so here is the next installment.

This mailing list post just hit the so-called Thunderbird UX mailing list. They author announces a redesign with the aim to simplify the Calendar UI, amongst other things. So what they have done is actually to remove functionality. But they author of the article preempts any concern by stating (quote):

These changes will be completely optional, kept in a separate “New Calendar” space, so those who need legacy features won’t lost access to any of their workflows.

How useful, so the rework will either be hidden, or users will hide it to get the functionality back that they need.

Thunderbird DOES NOT NEED yet another redesign and refactoring, what it needs is that the 2,538 open Calendar bugs be properly triaged and the most important ones fixed, like these:

Full list here, sort by Votes.

The Calendar component has been mostly abandoned since its Module Owner has moved onto greener pastures in so-called Thunderbird services (Thundermail, etc.). So now, instead of providing real functionality improvements, the Thunderbird folks have switched to polishing the turds.

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 (irony!) 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.

UPDATE 12th June 2026: So the feature got included in Thunderbird 153, currently in Daily/Alpha stage, going to Beta next week. As mentioned, an account indicator is only displayed in cards view and in the folder list. Apparently, the Thunderbird folks are seeking more complaints, since all people who haven't configured account colours will now get a rather useless additional blue indicator showing the default colour:

(Screenshot taken using some newsgroup content.)

And in the folder list:

How useful is that?

In Betterbird, we're maintaining the indicator, but we're not showing it, when no colour is set:

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.

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 has always been underperforming when measured against its own roadmaps. Now it looks like the roadmaps have been replaced by a list of what the project is working on anyway.

Let's compare the past and current roadmaps. We're focusing on the major items which have accompanied us over the last five years, of which at time of writing (April 2026) none are complete and only one, Exchange support, has a realistic chance of being completed.

Items marked with an asterisk for 2026 (Fluent, Exhange) may be complete for the summer release of Thunderbird 153, the global database will not be shipping in this release.

Important items, like replacing the buggy 26-year-old MIME library of finally providing a decent and contemporary mail editor, are not even on the roadmap.

It's no surprise that things are not progressing with the Thunderbird desktop development, since despite close to 60 staff (of whom 15 are managers, CEO, COO or directors), the project has "diversified" into Thunderbird for Android (rebadged K-9 app), Thunderbird for iOS and so-called "Services" where the project actually supplies mail accounts. A developer recently wrote that the desktop team was small; going by the mentioned page and not counting director/manager and release engineer, there are only 12 people.