Conversations for Thunderbird: a Gmail-style thread view in the mail client

What the extension changes in the thread pane

Conversations for Thunderbird improves the threaded summary for emails in Thunderbird, and the README is explicit that it takes some ideas from GMail. The listed changes are specific enough to be testable.

Your own messages are displayed in the thread, which is the single biggest change, because a threaded summary in Thunderbird traditionally shows the other participants and hides what you wrote. You initially see summaries, and they can be expanded to display full messages. Quoted sections are collapsed the way GMail collapses them. There are fast links for replying and possibly other useful actions, and you can reply inline through a quick reply feature.

That list describes an interface that treats a mail thread as a conversation rather than as a list of messages with a reference to a parent. The collapsed quotes are the detail that matters most for reading long threads, because in a standard client the quoted history is re-printed in every message, and a five message thread carries five copies of the same text.

The project describes itself as a Thunderbird extension rather than a fork or a theme, so it sits alongside the standard client and changes the reading experience without asking you to change anything else about how mail is handled.

Distribution through AMO rather than a build of your own

The README points to the addons.mozilla.org listing for screenshots and a stable version, and describes it as providing a ready-to-install package. That is the intended path for anyone who wants to use the extension, and it is the path that inherits the project's support policy.

The support policy is stated in terms of Thunderbird versions rather than in terms of dates. The project tries to ensure that the released version supports at least the latest released Thunderbird version, and where possible it also supports the previous Thunderbird version and the latest betas. The README is candid that support may lag depending on what has recently changed in Thunderbird.

That wording is a real constraint on adoption, not a disclaimer. An extension that targets the latest Thunderbird release and the previous one is fine for a user who updates regularly, and awkward for an organisation that pins a Thunderbird build for a year, because the extension you have installed will eventually be running against a Thunderbird it no longer supports.

The build from the repository is a separate path and the README sends you to a development document for it, with a contributing document and a licence file alongside. The repository layout shows a conventional web extension project: an addon/ directory for the extension itself, docs/, scripts/, types/, webpack.config.cjs, an eslint config, prettier configs, a tsconfig.json, renovate.json for dependency updates, and an AGENTS.md file.

A React and Redux extension with a modern toolchain

The package manifest describes a JavaScript project that uses React and Redux, and the dependency versions are pinned exactly rather than with ranges, which for an extension that has to work against a moving host application is the sensible choice.

The runtime dependencies are @reduxjs/toolkit at 2.13.0, react and react-dom at 19.2.8, react-redux at 9.3.0 and redux at 5.0.1. The manifest is marked as an ES module project and as private, with a note that the file is for build purposes only, and the version is 4.3.16. The Thunderbird engine requirement is declared in the manifest:

  "engines": {
    "thunderbird": ">=128.0a1"
  },

That floor of 128.0a1 is the concrete version constraint behind the support policy, and it is worth checking against the Thunderbird on your machine before you install anything.

The build and test tooling is modern and, notably, security conscious. The development dependencies include eslint 10 with the react, json, import-x, jsdoc, mozilla and no-unsanitized plugins, and the mozilla plugin is what brings Thunderbird's own lint rules to the table, which is how an extension avoids using APIs the host does not expose. There is prettier, TypeScript 6.0.3, webpack 5 with html-webpack-plugin, jsdom and the React testing library, and a compression override pinned to 1.8.2. The mozilla eslint plugin and the no-unsanitized plugin together are a signal that the authors expect the extension to be held to the host application's rules rather than to a looser web standard.

Scripts that build a web extension rather than a library

The scripts section of the manifest shows how the project is put together, and it is not a plain library build.

The dev script removes a development output directory, starts a build script in watch mode in the background, waits, and then runs a second script that serves the result:

    "dev": "rm -rf ./dist-dev-html && (scripts/build-dev-html.sh --watch &) && sleep 4 && scripts/dev-html-serve.sh",

The build script is a shell script, scripts/build.sh, and the production variant is the same script with a --prod flag. Formatting is prettier run in write mode over the whole project, and the test script chains a lint run and a TypeScript check before the test suite.

The shape of the dev command is informative about the extension model. A Thunderbird web extension has at minimum a manifest, a set of privileged pages, a content script and a background script, and it usually has a bundled web interface for the conversation pane. Building that means copying static HTML into the package, bundling the JavaScript, and producing an installable archive, which is why a shell script with a watch mode sits in front of webpack rather than a single npm script.

The scripts directory therefore contains the pieces that webpack.config.cjs does not, and the fact that the dev flow is written as a shell pipeline with an explicit sleep means the local development experience assumes a Unix-like shell.

Where the extension stops short

The first limitation is the one Thunderbird itself has been closing. Conversations for Thunderbird was created to fill a gap in Thunderbird's own thread view, and the gap has been narrowing: modern Thunderbird has its own conversation view, so the extension's advantage is now a matter of taste between two implementations rather than the difference between a broken summary and a good one. The features the README lists, summaries, collapsed quotes and quick reply, are the kind of thing the host application can also do, and if the host does them well, the extension is competing on polish.

The second limitation is the version coupling already described. The extension is a web extension running inside a host application whose internals change between releases, and the project says support may lag depending on what has changed in Thunderbird. An extension that is a week behind the host is a nuisance; one that is a year behind can be a broken pane.

The third is that nothing here touches the underlying mail store. Conversations changes how threads are rendered, not how messages are fetched, indexed or searched. If the problem is that a mailbox is slow to search or that conversations are grouped badly, the answer is elsewhere. What you get is a different reading of the same data.

The fourth is that the repository has no GitHub releases. The version tracked in the manifest is 4.3.16, but the distributable artefact a user installs comes from the addons.mozilla.org listing rather than from a tagged release, so the version you run is whatever was last signed and published there. The last push to the repository was on 2026-10-20, so work is happening.

The alternative is Thunderbird's own conversation view

The credible alternative is not another extension, it is the conversation view that ships with Thunderbird itself, and for many people it is the better answer because it is maintained by the same people who maintain the host.

The difference in approach is worth stating precisely. The native view is part of the application, so it is updated and tested with it, it has no version floor of its own, and it receives fixes when Thunderbird receives them. The extension is a third party layer that reaches into the host's rendering, so it can do things the native view does not do, such as its own quick reply flow and its own handling of how your own messages are shown, but it has to be re-validated every time the host changes underneath it.

There is a second alternative, which is a different client. A webmail interface, or a different desktop mail application, will render threads in its own way, and for someone who only reads mail in a browser the extension is irrelevant. The extension is for people who have committed to Thunderbird as a desktop client and want the conversation view of a webmail service inside it.

The practical test is small. Install the extension from AMO, read a long thread you already know, and check whether the collapsed quotes and the inline reply are worth the version coupling. If the native view already gives you that, the extension is adding a support dependency for nothing.

Editorial conclusion

Adopt thunderbird-conversations if you read a lot of threaded email in Thunderbird and the stock thread summary hides the context you need, especially if you want your own replies visible in place. Do not adopt it if you are on a Thunderbird build older than 128.0a1, or if you are happy with the native conversation view that Thunderbird itself now offers. Before you install from AMO, check that the listed version supports your Thunderbird release, and read the development documentation before building from the repository, since the build is a webpack setup with its own scripts rather than a single npm install and build.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. Project website
4. README
5. thunderbird-conversations/thunderbird-conversations on GitHub