2068847 - All incoming messages match a single filter in Thunderbird 155, despite valid conditions stored in msgFilterRules.dat

Status: UNCONFIRMED

(Thunderbird :: Filters, defect)

Description

[n.sakai]

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

Steps to reproduce:

Platform: macOS 26.6.2
Locale: ja (Japanese UI and Japanese filter condition values)
Account type: IMAP

1. Use a profile with multiple message filters created in Thunderbird 154, where filter conditions contain Japanese text values (e.g. subject contains a Japanese string).
2. Update to Thunderbird 155.0 on macOS.
3. Receive new mail.

Actual results:

Every incoming message is matched by a single filter, regardless of whether the message actually meets that filter's conditions. All mail is moved into that one filter's target folder.

The filter log confirms that one and only one filter is applied to every message.

If that filter is disabled, the behaviour does not stop: the next enabled filter in the list then matches every incoming message instead. Disabling filters one by one simply shifts the problem down the list, which suggests the conditions of all filters are effectively being evaluated as "match all" at runtime.

Expected results:

--- Expected results ---

Each filter should only match messages meeting its stored conditions.

--- Additional information ---

The on-disk rules appear to be intact. I inspected msgFilterRules.dat directly and the condition= lines are well-formed, with the Japanese condition values preserved correctly and no empty or mojibake values. This suggests the problem is not corrupted rule data, but that 155 fails to parse or evaluate the stored conditions correctly.

Because the stored data is valid, recreating the filters through the UI is not expected to help, and downgrading appears to be the only workaround available.

I can attach the relevant condition= lines from msgFilterRules.dat and the filter log output on request.

Comment 1

[Wayne Mery (:wsmwk)]

Any errors seen in Tools > Developer > Console?

Can you create a test filter to see if filters fail for English?

Comment 2

[Magnus Melin [:mkmelin]]

Please provide the msgFilterRules.dat

Comment 3

[n.sakai]

Thanks for looking at this. I ran some tests on the affected machine, which is still on 155. Summary first, details below.

The Japanese locale is not relevant, and the stored rules are not corrupted. The problem only appears when many filters are enabled at once.

Are both target and source folders imap?

The source folder is the IMAP account inbox.
The target folder is also IMAP (actionValue starts with imap://)

Any errors seen in Tools > Developer > Console?

No relevant errors. Nothing at all was logged when a message was filtered. The only entry I saw was a JSProcessActor error produced by opening the developer tools themselves, which is unrelated.

--- Test results ---

All tests were run with only the stated filters enabled and everything else disabled.

New filter created in 155, with a Japanese condition value, enabled alone:
Works correctly. A matching message was filed as expected, and a non-matching message stayed in the inbox.
=> The Japanese condition values are not the cause. Please disregard the locale detail in my original summary.

One pre-existing filter (created before 155, ASCII-only condition value), enabled alone:
Works correctly. A message that clearly did not meet its conditions stayed in the inbox.
=> The migrated rules themselves are not broken, and 155 can evaluate them correctly. This contradicts what I assumed in my original report.

Two pre-existing filters enabled together:
Works correctly. A message matching neither filter stayed in the inbox.

So the failure does not reproduce with one or two filters, but it reproduces reliably with my full set enabled. I have around 60 filters in this profile. With all of them enabled, every incoming message is matched by a single filter regardless of its conditions, and disabling that filter simply moves the behaviour to the next enabled filter in the list.

This suggests the problem is in how the filter list is evaluated as a whole, rather than in any individual rule.

--- Additional data point ---

I have a second machine still running Thunderbird 154, connected to the exact same IMAP account, with the same server, the same mailbox and the same folder structure. Its filters work exactly as before. Only the machine updated to 155 shows the problem.

Since both clients filter the same messages from the same account, this rules out any server-side or account configuration cause, and points to a regression introduced between 154 and 155.

--- Current status ---

I have disabled all filters on the 155 machine and I am doing the filtering from the 154 machine instead, so I can keep the affected machine on 155 and run further tests.

I have not yet bisected which subset of the 60 filters triggers the failure, as that is a lot of manual testing. If you can tell me what would be most useful, I am happy to run a specific test.

Comment 4

[Magnus Melin [:mkmelin]]

Please attach a filter log MOZ_LOG=Filters:5. See https://wiki.mozilla.org/MailNews:Logging

Comment 5

[Magnus Melin [:mkmelin]]

Do you have any rules that match "empty string"?

Comment 6

[Hartmut Welpmann [:welpy-cw]]

Simply enabling the filter log from the UI might already give some insights.

Comment 7

[Wayne Mery (:wsmwk)]

Thanks for testing the language.