Roadmap
This provides a listing of maintenance and feature work wanted for Thunderbird 91 (2021) release and beyond. How much of it we can do for 91 depends on how many contributors we have available.
Note: This is a work in progress - everything is subject to change.
The address book needs a big time refresh. We will design the address book so that it could work as a general utility, not only inside Thunderbird although Thunderbird is the primary consumer of it.
The new address book would live inside a tab, like calendar, tasks, and chat currently do.
UI changes to support vCard v4, e.g. specifying an arbitrary number of email addresses.
Convergence to make the fields available match what can be stored in vCard v4 (we have a few things that don’t; "ChatName", "preferDisplayName".)
It should use web technologies and not rely on XUL widgets - the new front-end is intended to serve as a testing ground for finding solutions that we will need also elsewhere in the UI as we converge towards using HTML.
Finish CardDAV support (tracker bug: bug 546932).
Get rid of the C++ address book providers.
Create JavaScript replacement for LDAP, but only implement the few features we use. This would allow dropping significant amounts of old C++ code.
Consider dropping the read-only OSX address book, and switch users over to using their read-write iCloud calendar through CardDAV.
The Windows address book has only ever been available behind a pref. Consider dropping it completely.
New address book tracked in bug 841598.
For localization Firefox is moving (https://arewefluentyet.com/) to Fluent, and Thunderbird will follow.
Firefox has officially deprecated the old style localization system since October 2019. Thunderbird should do the same: i.e. adding/changing strings only allowed for Fluent strings, with properties/dtd files basically freezed.
This is tracked in bug 1492751.
Thunderbird will move away from XUL documents and towards top-level (X)HTML windows. Thunderbird has over 200 top level documents, so this is a significant effort. Hopefully some scripting will help in pulling it through.
In parallel, the conversion from individual XUL elements to corresponding HTML ones will continue.
Thunderbird will no longer add new files using top level XUL.
The messenger.xhtml effort is tracked in bug 1570943.
Implement one protocol in JavaScript, and make it an option to use that implementation. The prime candidate to start with is SMTP.
Tracked in bug 1661694.
We should drop support for Movemail and clean up the account settings UI that is currently complicated by this. (“Other accounts -> Add News Account”)
Tracked in bug 1625741.
Implementing JMAP (RFC 8620) support at an early stage could be useful for getting experience in (re-)implementing protocols, without worrying too much about existing limitations, and at the same time obtain support for JMAP. It would also help move JMAP forward as a first rate protocol, and perhaps give us bragging rights as the first major email client to provide support.
Tracked in bug 1322991.
The odd Mork file/”database” format is very unapproachable, and hard to understand. We should pay away this technical debt to finally get rid of it, paving the way for more modern approaches, and enabling consistent, proper async database operations. Mork is used for
Address book data: tracked in bug 382878 [DONE]
Mork has been removed from the Address Book but while the code still exists it will be able to import Mork address book files (see bug 1664359).
Panacea.dat: tracked in bug 418551
Folder message indexing data (cache): tracked in bug 11050
To enable data migration, complete Mork removal would happen once a major Mork-free release is done.
Tracked in bug 453975.
Currently the index of messages is per folder (and based on Mork). This causes severe limitations to implementing a proper conversation view of messages. Especially for Gmail, there is also message duplication on the file system since their All Mail folder has all mails, but the other folders do not know about this… For our special message views (Unified Inbox etc.) and search folders, lack of a cross folder database makes the implementations far more complicated than they should be.
This work is tracked in bug 1572000.
Libmime is the cruftiest piece of code we have: it is hard to understand and its maintenance is error prone. The library is used all over the place, so to the extent it’s possible we should start converting code over one part at a time. A number of years back the MIME header parsing was converted over to using the JSMime JavaScript library, but the message body is still using libmime for parsing.
Message sending is very entangled with libmime. For Thunderbird 90 we will finish the rewrite of sending in JavaScript. This work is tracked in bug 1211292.
After that, we should also get started with using JavaScript for the body parsing of MIME. Add an option to use it so dogfooding can find problems. This is tracked in bug 1664150.
Investigate if integrating TNEF support can be integrated cleanly enough. If it can, we could integrate it. If not, we should take the needed steps to make it possible.
Tracked in bug 77811.
Our maildir support is pretty good by now. Finish up the last things needed to have maildir (our one file per message storage) on by default for new accounts.
Tracked in bug bug 845952
Using Array<T> instead of nsIArray in .idl files allows using XPCOM arrays as native JavaScript arrays. This is very helpful when rewriting a C++ component in JavaScript. It also gives nicer, safer, more modern code on the C++ side.
There are similar adjustments needed to get rid of some enumerators that are really arrays.
Tracked in bug 1583030
Fission is the next step of multi-process support from Firefox, where even different origins are separated into their own processes. Thunderbird needs to adapt its code to Fission, since eventually Fission will not be optional anymore. These architectural changes should also help with boosting performance.
Tracked in bug 1646648
We should provide better offline and slow-network support (use local data first; performance boost). Leverage existing browser level caching and offline support mechanisms to achieve this. To be able to use those, this means data access through HTTP or pre-fetched into an IndexedDB database.
Requires investigation of feasibility.
Implementing a better vertical layout by exploring the possibility of not using the <tree> XUL element and relying on a highly scalable and equally performant HTML component.
A first step before doing this will be to explore how to do it in the (new) address book view, which normally don’t have quite the same performance requirements.
Implement a “density” toggle to allow users to switch between “relaxed”, “normal”, and “compact” mode.
The folder pane should allow mixing multiple folder modes like Outlook. Thunderbird already supports different folder modes, but it’s currently one at a time. It would be much more useful to be able to show a section with (e.g.) Favorites on top, and All Folders beneath it. Allow the user to choose which modes to put where. Tracked in bug 1163555.
Allow reordering of accounts. Tracked in bug 418551.
Thunderbird top level UI is currently part of the chrome UI. With the target set on becoming a super fat privileged web application, this needs to be rethought: web applications live in content. It’s also become clear that the platform support for many features one can use in a web page using web technologies is implemented in a way essentially requiring the “page” to be located in a browser element (e.g. form controls and validation), and accessed through http (localStorage etc.). We should investigate to what degree we can move our chrome UI basically into a tabbrowser. Making sure we’re treated as an http accessed web page will enable many features without hacks: localStorage, IndexedDB, CSP etc. - even simple functionality such as opening new windows have caused breakage recently.
For add-ons wanting good access to modifying the UI, this would be a significant win, since WebExtensions are primarily designed for modifying content.
Requires investigation of feasibility.
Internally Thunderbird is using mailbox: and imap: etc. URI references to access the mail data. This area has proven to be very problematic. To eliminate much of these problems, we should separate out the data access providing that through IndexedDB database or over an HTTP internal API instead. This will make back-end/front-end separation much cleaner, and of course more webby.
Requires investigation of feasibility. But can fairly easily be done in pieces.
The editor will move to using web compatible composition. In Thunderbird 78 some of the formatting actions already started using document.execCommand, but there are more to do to finish this work. The goal is that editor bugs affecting editor on the web should also reproduce in Thunderbird, and vice versa.
Other features:
oEmbed/Twitter Card/Open Graph support: bug 1572648
Support markdown - and extensions to it allowing nice graphs etc.: bug 1280912
Refactor the text editor to remove as many dialogs as possible (links, colours, tables, etc) and offer a cleaner and inline editing experience.
Attachment pane improvements and unification with compose: bug 1640760
Make it easier to clear styles, so that user’s don’t need to worry about mixed font sizes etc.: bug 1667372
Implement an easier more convenient way to move between the different parts of the application (mail, calendar, tasks etc.)
Tracked in bug 1665511.
Encryption is an increasingly important part of email communication.
Thunderbird 78 added basic OpenPGP support, but there is still much much to be improved to make it easy to use, and to handle more complex setups.
The OpenPGP code needs more automated tests. The code also needs cleanup, e.g. to remove old code that we don’t use or that is no-op for other reasons.
Like SSH, we should move more towards trust on first use (TOFU). This would be more feasible if all incoming keys were automatically collected for possible usage later - at the moment without chores for the user, it does not work since the keys are not “known”, even if they have been sent to you. We should allow users to publish their key on keyservers for others to discover.
We should also implement the “encrypt-if-possible” mode (bug 135636). If keys are (thought to be) available for all recipients, in this mode mails would be sent encrypted, but would be sent unencrypted if they are not. A wizard type approach would guide the user to sending the email encrypted in case we have known keys collected, that would now be used for the first time. Should also consider “upselling” use of encryption where it would be possible.
Correctness fixes.
UX improvements to make it easier to use encryption. If keys weren’t already configured for the recipients users should be properly guided through the process. No internal knowledge of how OpenPGP works should be required.
Implement filter actions to permanently decrypt messages (bug 1627962)
Redesign the OpenPGP key manager and make it live in a tab instead of a dialog.
Meta tracker: bug 22687.
Wherever possible we should use UTF-8. This ensures message data is maximally compatible over time. It also simplifies the code base. Further, native JavaScript can’t encode to random charsets. As we move more code to using JavaScript using other charsets causes needless complications.
To support convergence server side a future with UTF-8 supporting servers should be encouraged.
Outgoing mail will be UTF-8 only (bug 862292)
Remove needless view charset overrides. (bug 1671880)
Support for SMTPUTF8 - RFC 6531 - (bug 1563891)
Support for UTF-8 IMAP store - RFC 6855 - (bug 1571672)
Thunderbird 78 already took the first steps towards an account setup that lets users set up all their services in a central location.
Going forwards Thunderbird should guide the user through an account setup process that sets up all the services they will need. The email address is often the connector that makes it possible to find mail + caldav calendars, + cardbook addresses, and more.
The account setup flow will move to a tab instead of a myriad of dialogs (about:accounthub).
Tracked in bug 1664179
Now that the compose window is using pills for addressing, it’s now possible to implement some addressing features that would have been difficult earlier
Mail Redirect support (in the UI) - backend support already exists. This is a fancy forward that puts you out of the loop.
Consider Resend/bounce support
Consider using RFC 5322 group addresses syntax support
Useful when sending to many people while wanting to keep the addresses private.
Putting some effort into making ical.js performant enough will let us drop our very old fork of the C++ libical and focus on making the JavaScript implementation great. For Thunderbird 90 ical.js would be on by default, but the old libical could be enabled if necessary. After Thunderbird 90, libical will be removed completely.
Tracked in bug 978570.
The calendar is eating a lot of the Thunderbird resources. Move the calendar to its own process, and figure out how it would communicate with the rest of the application then. Fission?
There are also many individual cases that could be tracked down through performance profiling.
Remove use of all calendar XPCOM components and replace them with simple JavaScript classes where possible. Reduce or eliminate XPCOM dependencies.
Event invite display will get an UX overhaul.
Event descriptions to support HTML display [DONE]
The current very technical table of event details will be replaced with a view that is more human oriented.
For the organizer, the data should become accessible (e.g how many people *are* coming to my event in the end)
Fix display of what’s changed for incoming events (current display is often confusing)
Reminders for RSVPs not replied to.
Support for counters (ability to suggest another meeting time)
Adding events directly to emails will also be made possible, and the UI for inviting to events vs. sending mails should converge.
The reminder feature is very aggressive. While sitting in front of the computer, we should show a gentle system notification that a meeting is starting, and allow joining that meeting if it’s online.
Tracked in bug 1497434.
Setting up events across timezones should be easy. Seeing the local time for the other event attendees would make things easier. The data is already more or less available to Thunderbird.
The Matrix network should be properly supported, allowing a Thunderbird teams type setup.
Tracked in bug 1572636.
The chat UI needs to be modernized. Compared to other parts, say calendar/tasks/addressbook it’s very “glued on”.
A sidebar to have in any windows would be nice for 1:1 type of communication.
Thunderbird should support smart widgets for voting, time scheduling. These could be built around micro-formats. For teams using Thunderbird only everything would work without problems (all over email). If someone uses another client, some manual actions would still be required. Fallback would still be pure text, so adding more structural data would give additional benefits only..
One way this would work for events is that we mark up the emails we send out with some structural data, say an hCalendar. When replying to a message, we check if the original mail had included an hCalendar, and can offer quick options to reply, and including that for that hCalendar event you are an attendee. It can also link to the UUID of an existing event in your calendar and offer response options related to that, e.g. check if you’d have conflicts in your schedule.
For things like simple votes, be smart and let a [vote](emoji) in the subject mean there’s a vote going on. Upon request by the user, create a voting summary and clean it up into a nicely formatted output. Automate the things that take some time to copy-paste from many mails, but could easily be automated. Make the Thunderbird users look good.
detect structured data (JSON-LD), allow acting on that data (see schema.org, xref KItinerary) — e.g. let you add flight data into your calendar directly
detect micro-formats [related to smart-widgets]
detect the most common free texts (especially: times and dates), and allow inline viewing of calendar schedules for that time, or contact information for a known contact in your address book etc.
improved support for drag-n-drop as well as copy-paste of many data types: mail data, events, tasks, contacts
Support the use case where a mail arrives only to give you a notification and a link. Allow Thunderbird to go grab the relevant data from that link and put it back into a message for convenient reading and archiving.
This is enabling the global data stream to be inside Thunderbird without much knowledge about the external forums etc. The feature will require some technical knowledge at least at first, but recipes on how to get data for various sources could later be created and shared by power users.
Add real support to import/export profiles, or single accounts. Look at the import/export tools add-on for inspiration.
Export folder/account: tracked in bug 752295
Import/restore folder/account: tracked in bug 247312
Import profile: tracked in bug 63389
Further email data exports through filter actions: tracked in bug 1664171
Storing text notes on the IMAP server would be useful, and the feature is low hanging fruit not necessarily very hard to implement.
Tracked in bug 713843.
Better support for mailing list handling:
Mailing list management UI
filtering to folders, autodetect lists and offer to set up
handle the case of 2 mailing lists being the recipient better
How to handle list encryption?
Rewrite into JavaScript. Move to async operations once that’s done.
Tracked in bug 1574136.
Thunderbird should continue to add more MailExtension APIs.
One of the main problems users have is that they can’t send/receive emails. Add a trouble shooter that could help diagnose the problem.
Set up performance measuring. Investigate performance bottlenecks and improve UI responsiveness and application startup time. Concrete goals to be set up once we have more information.
Firefox is currently reworking printing (print in a tab). This will cause some work to adapt.
We should also be able to improve the looks of printed mails by some fairly simple css adjustments.
system notifications (windows) - also improved notifications in general (there are a number of ways they are not as useful as they could atm.
mid: links to be fully supported and Thunderbird should register itself to open mid: links - would be super helpful for cross referencing of mails, events, and tasks, even from other applications. Bug 264270.
calendar: Thunderbird 78 added the ability to handle adding and opening of .ics event attachments by double click: bug 357480.
XMPP/Jingle support. Bug 1018060 [If we can get sponsorship?]
Consider an option to connect through Tor. Some mail providers support connecting through their onion services.
For the general Tor uplift effort at Mozilla, see https://wiki.mozilla.org/Security/Tor_Uplift/Tracking
Thunderbird will move to use a single repository for all the code to stop all the problems that have to do with the mozilla-central comm-central split. Instead Thunderbird code will live in a separate repository that is based on mozilla-central but has a comm branch carrying a comm/ subfolder.
Tracked in bug 1666242.
Thunderbird localization will start using its own localization repository. This will allow us to do string changes in point releases when needed. This is currently not possible due to technical constraints in how the localization system is set up.
To make it easier to follow Firefox release engineering changes, we try to further align with the Firefox release setup. The single repository will help in that we don’t need to check out more than one repo. Ideally only the repo url and some config variables would have to be different, except for product specific build needs.
Make the web site more marketing focused with stories on how to best utilize various features in Thunderbird and highlight workflows.
Our current donation appeal shows up only after users’ download starts. We should consider a more aggressive up-front appeal that would happen before the download starts. (Users could still choose to pay 0.)
