1977855 - Synchronize the most recent 1 month” - Instead of syncing the most recent month, Thunderbird begins syncing from the oldest messages in the account (starting in 2008), rather than downloading the most recent month

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, defect)

Description

[Stephen]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36

Steps to reproduce:

I'm currently using Thunderbird 128.11.0esr on Linux (MATE desktop).

The Thunderbird web extension API apparently requires messages to be downloaded and stored locally to access their full content via the getFull() endpoint. There appears to be no way to programmatically trigger a message download from IMAP using a message ID or header. Please correct me if that's not true, but I've read the documentation carefully and cannot find this behavior explicitly documented.

As a work around, to minimize disk usage, we only want to store the most recent 30 days of messages locally. To accomplish this, I enabled “Synchronize the most recent 1 month” in Account Settings → Synchronization & Storage in the Thunderbird GUI. All folders were checked in the advanced settings. I then removed my Imap folder from the profile directory, saved the settings and reset Thunderbird, and allowed it to download and repair the account folders.

Actual results:

Instead of syncing the most recent month, Thunderbird begins syncing from the oldest messages in the account (starting in 2008), rather than downloading the most recent month (e.g., June 15 – July 15, 2025).

Expected results:

Thunderbird should download and store only the most recent month (by date) of messages (e.g., June 15 – July 15, 2025).
Ideally, the messages.list() or query() methods should pull the most recent messages in the first page, rather than the oldest messages. The current behavior pulls the oldest messages first, which is generally not conducive to development. I greatly appreciate any relevant work arounds, including a way to circumvent having to download full messages from IMAP to get message content (via getFull or getRaw endpoints) if there is one. Please direct me to relevant documentation if I have missed something. Thank you!

Comment 1

[Magnus Melin [:mkmelin]]

All the headers need to get downloaded, the setting you found is just about the message bodies. Did it download the bodies?

Comment 2

[John Bieling]

As Magnus said, only the headers are pulled automatically. The API should then pull the required bodies on demand, when getFull() or getRaw() is used.

Can you confirm this?

Comment 3

[Stephen]

Thank you both, and apologies for the delayed response.

Yes, the headers do download correctly. The issue I'm running into is that messages.query() retrieves message headers in oldest-first order. For most use cases, especially when developing a message browser, users expect to see the newest messages first. Because of the current ordering, I had to build a workaround: query a one-week time window, iterate through all returned pages to ensure I capture the entire set, then reverse the results to present the newest messages first. The difficulty is that the number of messages in any arbitrary time window is unpredictable; it may return only a few messages, or several hundred, making it hard to present a consistent and user-friendly page size.

Could you clarify whether there is a way (or a planned enhancement) to request headers in descending date order or otherwise retrieve the most recent messages first? That would make the behavior much more consistent from an API-consumer perspective.

Thanks again for your help and for maintaining this excellent project.

Comment 4

[John Bieling]

That is an interesting scenario. I think adding a sort property to the queryInfo object will be a useful addition, not only for your use-case.

Comment 5

[John Bieling]

Hm, after looking at the code, I don't think we can provide that at the moment. We do not have a global message database, and run over each folder, returning all messages as soon as we found them. If we have to hold back all messages until we have found all to sort them, the query will be massively slowed down.

Are you querying all folders, or just a specific folder? I could add the sort property to browser.messages.list(), which only acts on a specific folder.

Comment 6

[Stephen]

Thank you, this makes sense and I really appreciate the explanation.
To answer your question: yes, I am querying specific folders, not the entire account. My main goal is to present message headers in consistent, predictable page sizes (e.g., ~100 per page) starting with the most recent messages first. I initially avoided using messages.list() because it doesn’t support date filtering. In a large folder with many years of email, calling list() would start returning the oldest messages first, which means I would have to retrieve the entire folder and then reverse it just to show the newest messages, which conveys a major performance hit.

If a folder-specific list() call could retrieve messages in reverse chronological order, that would solve most of my challenges and make pagination both efficient and user-friendly.

Directly related to this, I’ve noticed that new message headers must first finish downloading from the IMAP server before they appear in either list() or query(). Thunderbird shows this progress visually in the UI, but for blind users this status is not accessible. From the extension side, is there any way to detect whether header synchronization is currently in progress, or when it is complete? That would allow me to ensure that list() is returning the latest messages available on the server rather than only what has already been synced locally.

Thanks again for considering these use cases. I know they’re edge cases, but they’re important for building a responsive message browser with accessibility in mind.

Comment 7

[John Bieling]

way to detect whether header synchronization is currently in progress, or when it is complete?

You should receive a browser.messages.onNewMailReceived event, when a new message header is added to the system. Before that, the message simply does not exist inside of Thunderbird.

https://webextension-api.thunderbird.net/en/mv3/messages.html#onnewmailreceived

Comment 8

[John Bieling]

Attachment: Bug 1977855 - Add sorting support for browser.messages.list(). r=#thunderbird-reviewers

Add-ons can currently sort returned messages only after receiving all
of them. The time-consuming part of this operation is creating the
WebExtension MessageHeader objects and passing them across the process
boundary. It is therefore faster to sort messages before passing them
to the extension.

The extension may still need to wait for all messages, but it can
already process or display the ones it has received while waiting for
the remaining message pages.

Once the global message database is in place, entries could be sorted
directly during the lookup request, which would be even faster.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/611194dcde93
Add sorting support for browser.messages.list(). r=freaktechnik

Comment 10

[John Bieling]

The API addition has landed, messages.list() now supports an optional options parameter:

const messageList = await browser.messages.list(folder.id, options);

with options being defined as:

          {
            "name": "options",
            "type": "object",
            "optional": true,
            "properties": {
              "sortType": {
                "type": "string",
                "description": "Specifies how the returned messages should be sorted. Default sort order is <var>descending</var>, if not specified otherwise.",
                "optional": true,
                "enum": [
                  "author",
                  "date",
                  "flagged",
                  "junk",
                  "junkScore",
                  "priority",
                  "read",
                  "recipients",
                  "size",
                  "subject",
                  "tags"
                ]
              },
              "sortOrder": {
                "type": "string",
                "optional": true,
                "description": "The sort order for the returned messages. Ignored if <var>sortType</var> is not specified.",
                "enum": ["ascending", "descending"]
              }
            }
          },

So a possible use case is:

const messageList = await browser.messages.list(folder.id, { sortType: "date", sortOrder: "descending" });

It will be available in today's or tomorrow's Thunderbird Daily, in Beta and Release 148, and in the next ESR released in summer 2026 (no backports).

Feedback is appreciated.