STR:

1. Send a message to yourself from a different mail client.
2. Note that Thunderbird shows a new message in the taskbar.
3. Read the message in another client.
4. The taskbar icon will never disappear until you click on a folder.
5. In 102 the taskbar updates within seconds of the message being read on a different client.

I suspect that the _updateUnreadCount function is not being called in every case that it used to be, but not 100% sure.

Bug 1791160 perhaps?

Assigning this to Vineet so he can investigate the issue and try to reproduce and fix it.

I think there's more than one issue as I've also noticed Daily not responding to IMAP updates as frequently.

Probably should do a regression range with the tool first. I thought that was enough to get Alice to do it but maybe a needinfo?

@Alice could we get a regression range for this one?

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=5abcc1359eb7d4122f958a823e29b43de5f60b2e&tochange=45322ce67587354eda7948319caa349c5bba6ece
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=60b4965aa0ca5a7a60c71229600092a65df8bc1d&tochange=63a3d733b2331033f48d10995ce09abf50def953

Likely from bug 1805186 then. Tentatively marking it as regressed by that.

I don't have a " task bar" that shows TB message info so I can't see the described problem, right off. (I'm on linux KDE).
However, I do see one difference between 102 and my current 114 daily/self-built: When a new messages comes in and I mark it read at a different client (other TB instance), the "Orange asterisk" on the folder and by the new message for 114 doesn't go away, but the message does get marked read (un-bolded) and the unread count beside the folder goes down by one. With 102, the "orange asterisk" goes away automatically after the message is read on the other client. On 114 the asterisk goes away only after I select another message.

I thought the "orange asterisk" was controlled by the imap RECENT flag but I'm not seeing RECENT flag set or cleared in the 114 or 102 imap log. (RECENT flag, per RFC 3501, is only set and reset by the server, not the client).

Anyhow, I think maybe the stuck-on "task bar icon" that the reporter describes is caused by the same thing as the "orange asterisk" that also doesn't auto-clear with 114. I'll look and see if bug 1805186 is causing this, or maybe it's something else.

(In reply to Andrei Hajdukewycz [:sancus] from comment #0)

STR:

1. Send a message to yourself from a different mail client.
2. Note that Thunderbird shows a new message in the taskbar.
3. Read the message in another client.
4. The taskbar icon will never disappear until you click on a folder.
5. In 102 the taskbar updates within seconds of the message being read on a different client.

I'm seeing a lot of variant behavior depending on the imap server even with 102. Can you tell me the type of imap server you are talking to?
I've seen the problem described in STR with 114 on Cyrus and on iCloud imap (looked OK with 106). They both send back a bad imap response when tb asks for a "preview" of the message (to show the leading text in the popup) which breaks the connection until you click on another message.

FWIW, I'm thinking my concern about the RECENT flag in comment 6 is a red herring.

(In reply to gene smith from comment #7)

(In reply to Andrei Hajdukewycz [:sancus] from comment #0)

STR:

1. Send a message to yourself from a different mail client.
2. Note that Thunderbird shows a new message in the taskbar.
3. Read the message in another client.
4. The taskbar icon will never disappear until you click on a folder.
5. In 102 the taskbar updates within seconds of the message being read on a different client.

I'm seeing a lot of variant behavior depending on the imap server even with 102. Can you tell me the type of imap server you are talking to?
I've seen the problem described in STR with 114 on Cyrus and on iCloud imap (looked OK with 106). They both send back a bad imap response when tb asks for a "preview" of the message (to show the leading text in the popup) which breaks the connection until you click on another message.

It's Fastmail which does use Cyrus IIRC. I will test this on Google also later just to see.

From comment 7:

They both send back a bad imap response when tb asks for a "preview" of the message (to show the leading text in the popup) which breaks the connection until you click on another message.

I found what is causing this. I chopped out a bit too much "mime" related code on nsImapServerResponseParser.cpp.
But it seems that the problem occurs only (mostly?) when there is no offline store on the Inbox, as I typically run.
So I'm wondering if reporter Andrei is using offline store on the Inboxes that have the problem?

What's happening is imap server response "BODY[TEXT]<0>" occurs when a preview is requested and, since the code to handle this got taken out by me, a syntax error is caught which causes the thread to die and the imap connection to go down, so it's unable to report the "recent" message count until the user clicks a folder or message or until the next biff interval occurs to check for new mail, both of which usually start a new thread and imap connection.

I'll go ahead and submit a patch to fix this, but I've seen other problems too. Like if I toggle a message read/unread on TB instance 1, and monitor the same message on TB instance 2, TB instance 2 eventually runs into an error transitioning in/out of IDLE state and the connection shuts down. I need to look closer at what's causing this. (I also see the same problem when I toggle the "star" flag on a message, which is expected since it also relies on imap IDLE working correctly for both instances to remain in sync with imap message flags.)

Error caused connection to drop after new message arrival which can cause the reported problem:
Windows taskbar notification not properly updated.
But there may be other issues causing this too, but this one is probably the main one.

(In reply to gene smith from comment #9)

So I'm wondering if reporter Andrei is using offline store on the Inboxes that have the problem?

Yes, always use offline support as that's the default and I never uncheck it.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/08af69b87678
Fix regression caused by Bug 1805186. Syntax error on preview response. r=mkmelin

Comment on attachment 9333830 [details]
Bug 1831969 - Fix regression caused by Bug 1805186. Syntax error on preview response. r=mkmelin

[Triage Comment]
Approved for beta

Thunderbird 114.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/bbe32a304da9