User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36

Steps to reproduce:

The systray icon informs of 1607 unread messages. This seems to be the sum of unread messages in the inboxes. I have in excess of 20.000 unread messages which were moved by filters in other mailboxes.

IMHO, the systray should inform of new unread messages since the last start.

Looks like the code is here
https://searchfox.org/comm-central/rev/74693e927d8a79338c0a0aa5359e4ed5a8a32158/mailnews/base/src/MailNotificationManager.jsm#409
and the module shouldn't keep track of unread messages, but new messages. Now every time I start TB I get the tray icon telling me that I have 1600+ unread messages. IMHO, that is not useful.

Why is onCountChanged(), sometimes called with unread messages and sometimes with new messages? Seems inconsistent:
https://searchfox.org/comm-central/search?q=onCountChanged&path=MailNotificationService.jsm&case=false&regexp=false

Have you tried setting mail.biff.use_new_count_in_mac_dock to true? https://searchfox.org/comm-central/rev/74693e927d8a79338c0a0aa5359e4ed5a8a32158/mailnews/base/src/MailNotificationService.jsm#25 https://searchfox.org/comm-central/rev/74693e927d8a79338c0a0aa5359e4ed5a8a32158/mailnews/mailnews.js#880-883

No I hadn't at the time of the previous comments. Setting this hidden pref works fine on Windows. IMHO, this should be

1. renamed (comment says: When we go cross-platform ... - you are cross platform now, aren't you?)
2. made visible
3. set to true by default on Windows.

Otherwise for Windows users who are in the vast majority (https://stats.thunderbird.net/#platlang: Windows: 95%, Mac 4%, Linux 1%) this is very confusing.

Cheered too early. With the pref set, only the new messages are shown in the Windows badge tooltip. That's good, but the badge seems to be cleared when the first new message is read, it should be maintained until all new message are read (at least that happens when new messages are in different folders via filters). This needs more work.

Oh right, mail.biff.use_new_count_in_mac_dock means new since the last biff. MailNotificationService.jsm was introduced years ago, I didn't touch it.

Because we don't differentiate new messages of the current session from other unread messages anywhere in the UI, it's hard to say showing new count of the current session is better than showing all unread count. That would be a new concept to the users.

To me, if I have no intention to read some mails immediately, I would filter them to a normal msg folder.

That would be a new concept to the users.

Not at all. Users are used to folder badges, see enclosed, and message badges (I'll attach later).

What is implemented now isn't doing the users any favor: With the pref at default value, they get the sum of unread messages in all the inboxes (not useful), with invisible the pref set to true, they get notified of new mail as expected, but the systray is cleared as soon as a) a new message is read or b) a folder containing a new message is opened.

Those badges disappear as messages are read or folders are visited, and they don't reappear after a new start of the app.

In TB 78 the systray showed an envelop icon whose tooltips was: <account> has 1 new message.
Clicking the envelop icon brought up a window with a message preview that was clickable and (with luck) took you to the message (unless it was moved by a folder).

Looks like this functionality has been removed in TB 91 and replaced by a static icon whose tooltip isn't helpful. This could cause a few unhappy users. Marking this as regression (as compared to the previously more useful behavior).

The screenshots are biff state as well, you open the folder and then open another folder, those styles are gone even if you didn't read any new mails.

The old biff tray icon had many problems, it was decided to change to the current in bug 715799 Comment 30.

Thanks for the discussion and all the insights. Resetting the count to 0 in BiffState change seems dodgy, as the comment says. This in an improvement over the current state:
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/1721063-Windows-systray-tooltip.patch
Feel free to adapt to your needs.

This works well enough, however, it exposes bug 249271, bug 696703, bug 632372, bug 472713, bug 697341 and bug 1545955 which are all the same problem. With filters in place, the unread count is only reduced to zero if the folder/account is clicked which originally received the messages moved by a filter. See bug 1545955 comment #0 and bug 1545955 comment #5 which has a nice illustration.

FYI, we implemented a systray tooltip with new message count and the respective folders.

(In reply to José M. Muñoz from comment #10)

In TB 78 the systray showed an envelop icon whose tooltips was: <account> has 1 new message.
Clicking the envelop icon brought up a window with a message preview that was clickable and (with luck) took you to the message (unless it was moved by a folder).

Looks like this functionality has been removed in TB 91 and replaced by a static icon whose tooltip isn't helpful. This could cause a few unhappy users. Marking this as regression (as compared to the previously more useful behavior).

Argh...
at least I made my bug [RFE] so that it is known that the function has been removed and will be implemented again. And bang my bug is classified as a duplicate. No wonder why I don't like all this stuff....

At least José M. Muñoz in comment #10 got it. And what happens now? Are these typical "progress demands victims" people at work again? You can already hear that a little bit. "There were problems" so we can throw it out. Why don't you just throw Thunderbird out completely? Do it!

Fact: Thunderbird has been reduced by one very useful feature. -1,000,000 Mega Skills.

(In reply to José M. Muñoz from comment #10)

In TB 78 the systray showed an envelop icon whose tooltips was: <account> has 1 new message.
Clicking the envelop icon brought up a window with a message preview that was clickable and (with luck) took you to the message (unless it was moved by a folder).

Looks like this functionality has been removed in TB 91 and replaced by a static icon whose tooltip isn't helpful. This could cause a few unhappy users. Marking this as regression (as compared to the previously more useful behavior).

There is also some discussion about this bug over here - http://forums.mozillazine.org/viewtopic.php?p=14901960.

I echo all of José's sentiments. Why remove this handy preview? If you have multiple accounts set up in Thunderbird, the tooltip isn't very helpful. Also, the indicator dot is also very passive and doesn't stand out unlike the previous envelope icon.

On preferences page, show dock options on Windows as well.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/55554239cc72
Migrate mail.biff.use_new_count_in_mac_dock to mail.biff.use_new_count_in_badge. r=mkmelin

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b99d763dbae3
followup - Fix ifdef blocks in general.inc.xhtml. r=mkmelin

Comment on attachment 9238848 [details]
Bug 1721063 followup - Fix ifdef blocks in general.inc.xhtml. r=mkmelin

Request for the two patches
[Approval Request Comment]
Regression caused by (bug #): 715799
User impact if declined: Tray icon shows unread by default, and mail.biff.use_new_count_in_mac_dock is hidden on Windows
Testing completed (on c-c, etc.): beta
Risk to taking this patch (and alternatives if risky): the first patch added a l10n string, not sure how to handle it. Also the behavior of tray icon is changed to show NEW by default on Windows

Comment on attachment 9238848 [details]
Bug 1721063 followup - Fix ifdef blocks in general.inc.xhtml. r=mkmelin

[Triage Comment]
Approved for esr91

(In reply to Ping Chen (:rnons) from comment #23)

Risk to taking this patch (and alternatives if risky): the first patch added a l10n string, not sure how to handle it.

Assuming the string has been translated, the l10n-changeset pinning can be updated so that the new string gets picked up. I don't have a good sense of how often translators are working with Thunderbird translations. If they keep up with the beta cycles it's not a problem.
Honestly, it's better to rework it the patch the avoid the new string if possible. But since we have to get translators to do a bunch of retranslates for bug 1728893 we can probably get this through without too much trouble.

Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/9571278fbd2e
Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/38ab00f6aff2