Open Bug 1840255 Opened 2 years ago Updated 11 months ago

**Starting in version 102** New message indication in folder pane unreliable

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Version:
Thunderbird 114
Platform:
x86_64
Linux
Type:
defect

Tracking

(thunderbird_esr102 unaffected)

Tracking Flags:
Tracking Status
thunderbird_esr102 --- unaffected

People

(Reporter: steve, Unassigned, NeedInfo)

References

Details

(Keywords: regression, regressionwindow-wanted)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

A. Observed new message indicator in folder pane
Clicked on folder to check new messages

B. Observed new message indicator in folder pane
Clicked on folder to check new messages

C. Observed NO new message indicator in folder pane
Clicked on folder to check new for messages

Actual results:

A. No new messages.

B. New messages had arrived, subject in bold but no new message indicator to the left.

C. New messages were indicated in the message list of the folder

Expected results:

A. B. C. If there are new messages it should be indicated in the folder pane, there should be new messages with a new message indicator to the left.

OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Whiteboard: [Supernova]

Not present in 102.12

I confirm this is a bug. I first experienced it in 114b1. I have not evaulated it with any prior releases (114b1) but it does not exist in 102.

I should have noted I a(In reply to Steve from comment #2)

I confirm this is a bug. I first experienced it in 114b1. I have not evaulated it with any prior releases (114b1) but it does not exist in 102.

I'm using a Windows 10 / x64 machine and TB 115b6.

See Also: → 1840246

Steve, thanks for reporting this.

There are indeed still lingering message list issues. Check for 116 beta in about 24 hours, and let us know if it still happens. (and even 116.0b1 may still have issues)

Component: Untriaged → Folder and Message Lists
Flags: needinfo?(steve)
Blocks: sn-msglist
Whiteboard: [Supernova] → [Supernova3p]

This is still happening in 116.0b1

Flags: needinfo?(steve)

This is still happening in 116.0b1

And it's still occurring in 116.0b2

And it's still occurring in 116.0b3

So what do you need from me to confirm this issue? I'm at a total loss as to how to go about resolving this. I've uninstalled all TB instances and reinstalled 102 as well as 116 and the issue still exists in 116 but not 102. The fact that others have reported the issue should give some credence to it. I realize it's not a show stopper especially if the majority of the users aren't experiencing it. I realize you have limited resources and are only addressing the show stoppers but I have to tell you as someone who has donated dollars I feel a little left behind. I don't expect the organization to stop and address this immediately but some help at some point would be appreciated.

Below is my original post and I was not aware there was already a post. So I'll include it again.

I have two releases of TB installed. The first is TB 102.12 installed that I use as my production mail.
I have also installed TB 115b6 to make sure I can easily migrate when TB releases 115.

They use different email accounts so there is no overlap.

In TB 102.12 when a message is marked as "read" the font changes to normal while other unread messages remain bold. It has been this way for innumerable releases.

This does not occur in 115b6 (or in 114b1 and other beta releases).
The font remains bold even after the state of the message changes to "read".
I've kept all my settings between the two versions the same so I can see the differences.
I set messages to be marked as automatically read immediately on display.

So far this seems to be the only difference of any significance (at least to me).
I have done the standard uninstall, remove all traces and reinstalled TB but can't get this feature to work.

Is there a setting or configuration change I should be making that I don't know about?
I tried comparing the config settings but got overwhelmed with the sheer number of comparisons.

Thanks.

I have no trouble with the bold changing to not-bold when a message is read, the little green dots may or may not be against an unread message or appear randomly. In 102 the new message gold sparkles stay against the new messages until the folder is changed to another folder.
I just saw a sparkle on my TBbeta folder, clicked on it, the new messages all had sparkles and were bold but no green dots, then a minute later the sparkles disappeared so I no longer know what is new without looking at the time, then a few minutes later the green dots appear against the unread messages.
openSUSE.

I just clicked on another folder with a sparkle, the new messages have no sparkles but they all have green dots.

The inbox seems the best behaved, not sure if it ever has problems, I don't know if this is an issue handling Gmail labels.

Confirming based on two reporters.
Please post your results after using 116.0b4 early this week, and also 116.0b5 which should be avilable later in the week.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(steve)

116.0b4 still exhibits the behavior. However, the message indicator turns off. That is, when the message arrives the indicator is green and when the message is highlighted the indicator goes off but all of the text (Subject, Date, Correspondents etc.) remains highlighted in bold and does not go to normal.

Continued issue in 116.0b5

Continued issue in 116.0b5

Continued issue in 116.0b6(In reply to Steve from comment #13)

Continued issue in 116.0b5

I meant Continued issue in 116.0b6

Continued issue in 116.0b7

And 117b1

Confirm also in 117.0b1 on openSUSE, switching back to 102.

Flags: needinfo?(steve)

There may be a slight difference of experiences here...

(In reply to Steve from comment #8)

This does not occur in 115b6 (or in 114b1 and other beta releases).

But I believe Steve Edmonds' comment 0 is with 115 beta

It will be great if you can both find a regression range using https://mozilla.github.io/mozregression/quickstart.html
I would start with nightly build date range of 2023-05-20 and 2023-07-04

Flags: needinfo?(steve)

From comment 2 it seems possibly from 114b1. I selected 115 because I was a bit frustrated at that point but fairly sure it was happening in 114.

Flags: needinfo?(steve)

See bug 1840246
On Windows 10 /x64 I've narrowed it down to between release 110b4 (no problem) and 111b1 Build 1 (problem appeared).

117.0b2 problem continues

(In reply to Steve X from comment #20)

See bug 1840246
On Windows 10 /x64 I've narrowed it down to between release 110b4 (no problem) and 111b1 Build 1 (problem appeared).

The time frame Steve X gives in comment 20 110b4 to 111b1 matches to the merge of supernova code into nightly builds, which then became 111b1, i..e the very start of supernova.

If Steve Edmonds was using betas prior to 114.0b1 and did not experience the problem:

Version: Thunderbird 115 → Thunderbird 114
See Also: → 1835548, 1831488

102 has previously had 2 child processes, 110 onwards only seems to have 1. 102.15.0 now only seems to start 1 child process.
I think I am starting to see this bug in 102.15.0. It can often take some time to confirm this due to the randomness.

I am definitely seeing this issue in 102.15.0 and not in 102.13.0.
I have a suspicion this is to do with push notifications not working consistently in folders (labels) on gmail IMAP connections, Account Settings > Server Settings > Allow immediate server notifications when new messages arrive. I have checked this and consistently 102.13.0 has receipt notification a few seconds after sending a new email. The results are variable in 102.15.0, sometimes it can be 15-30 seconds, other times not at all and new mail does not show until I click on the folder.

I don't know if the number of folders has any effect. What happens if there is not enough time to check all folders within the time set in Account Settings > Server Settings > Check for new messages every ?? minutes

I have been running 115.2.1 for a few days and not observed the issue, checking 115.2.2 now.

Still have the issue in both 115.2.2 and 118b3

I went way back to 102.13 and tried all the betas from 110 onwards.
I don't think the issue is related to the change that reduced the number of child processes. I believe at present the issue started between 115.0b1 and 115.0b3. there are 2 builds of b2. It can take 24 - 48 hrs to be sure the issue is not present so is a slow process.
I saw it in 115.2.2 this morning and now back on 115.2.1 to recheck as I had not seen it there.

Not sure if it is related, running from the console for 115.2.2 I received quite a few messages;
[ERROR style::stylesheets::rule_parser] Saw @import rule, but no way to trigger the load

Not sure I was getting these in 115.2.1 so checking that also.

Unfortunately 115.2.1 now seems to show this issue. I will go back to the early betas and see if I can find the change point. What I have noticed in the last 3 or 4 folders that failed to indicate new mail is the following.
Normally when you click on a folder (not inbox, inbox always reports new mail) you get progress messages in the bottom of the window "opening...", "Checking..." etc. and these messages are quite brief. In the folders that have failed to report new mail these messages are quite slow. Not all folders for an account are slow.

Observations to add here. Hope they help.
I am currently running 115.2.2 (64-bit).
A while back, using a different release, I took screenshots to document the problem, and I noticed that the problem only seemed to occur when the Message Pane (F8) was on. My computer died before I was able to post my findings, and I don’t remember what version I was running then.
The problem seems to have evolved. TB behavior is generally better.
Now I have a new computer, and for a while only used Thunderbird with the Message Pane turned off. Now I’ve turned it back on.
This week I noticed something specific, and replicable:
When getting new messages (I use POP3) while looking at a folder to which some of those messages will be filtered (not while looking at Inbox), when that folder is sorted by date (descending), the newest arrived message always lacks the new message indicator (a yellow diamond in the dark mode I use). If a newer message arrives, the formerly newest gets its new message indicator, while the new newest does not get one. Then, you can see the indicator flash on ever-so-briefly when you click on that new newest. If only one new message arrives, and you don’t click on it, you may not see that any new messages have arrived in the folder.
For example, between the before-and-after screenshots I can't seem to upload here (so am linking below), “It’s worth a try” originally arrived without the indicator, but got the indicator when “⭐Newsletter TicketOne” arrived (without indicator). And so forth, until “3 Long Island Schools” arrived last, without indicator. Then I clicked on “3 Long Island Schools” and saw its indicator flash and go away.
Screenshot Links:
https://1drv.ms/i/s!AkjpCx43l1m4ksAT_yuJMaU5YdyjCQ?e=0LO3dH
https://1drv.ms/i/s!AkjpCx43l1m4ksAUNZ81QyZ5ShXVYg?e=RxVSzR
(note: “A.Word.A.Day--rubricate” is dated an hour before “Tuesday’s briefing”.)

I have been working my way backwards through the betas, it is slow as it can take a while to confirm the issue. 110.0b1 currently seems OK. 111.0b1 is not.
Currently there is a clear visual difference between 110.0b1 (and 110.0b4 I am now checking) and 111.0b1 in that 110.0b1 honours style settings I made in 102 and 111.0b1 doesn't.

Another observation is that in 111.0b1 "Get all new messages" doesn't check all folders, many of the folders that are labels in Gmail accounts are not checked, or if they are new mail is not indicated until you click into the folder.

I think 110.0b4 is indicating new mail reliably, 111.0b1 doesn't, so the bug seems introduced by 111.0b1. The first nightly of 111 is 16-Jul-2023 20:12, 111.0b1 is 26-Aug-2023 20:56 so about 40 builds between. I think the same bug has been introduced into 102.15.

I have been working my way through dailies and wondering if this bug involves 2 separate issues.
111.0a1 (2023-01-17) seems OK
111.0a1 (2023-01-18) has the issues but often falsely indicating new mail when there isn't any.
111.0a1 (2023-02-01) by this build TB is still falsely indicating new mail when none, but predominantly doesn't indicate new mail when there is new mail.

Certain folders are always correct, like inbox. Some Folders (gmail labels) are hit and miss if they show new mail and some consistently don't show new mail. It is as though TB is scanning a list of folders to process and gets interrupted part way so the further a folder is down the list the more chance new mail won't be identified.

I will head back to 102, which I suspect now has this issue, and verify this and if so start working through the dailies.

I admire your perseverance. I hope you can figure this out. It drives me mad.

Do you have a lot of folders to check, I have a total of 169 over 7 accounts and wonder if that has any significance.

Given comment 24, rolling back the idea, for now, that this started with 111.

When using version 102, on the account do "Search Messages" and just search on subject with one space so that all the folders get loaded. It should cause all the folders to have their information updated, and the folder should properly indicate whether it has new mail.

From there, after a period of days see whether the incorrect behavior comes back.

(In reply to Steve Edmonds from comment #32)

I have been working my way through dailies and wondering if this bug involves 2 separate issues.

The mozregression tool will help you in this process, as well as being able to cast a broad net (range of dates). Doing dailies piecemeal is going to be slow and perhaps error prone

No longer blocks: sn-msglist
Flags: needinfo?(steve)
Keywords: regressionwindow-wanted
Summary: New message indication in folder pane unreliable → **Starting in version 102** New message indication in folder pane unreliable
Whiteboard: [Supernova3p]

Just to clarify wrt 102, I should be looking for the point I may have observed this between 102.13 and 102.15? This bug can show quickly or slowly over 48 hours, not sure if that is just related to arrival of mail.

Re. your instructions, I just tried in 115.3.2 (showing the bug) right click on an account in the folder list of classic view, Search Messages with settings search folders, run search on server, match all of the following, and with Subject Contains put a single space in the entry box.
I get multiple errors - mail server for the account responded [SERVERBUG] infeasable query (failure). I assume this is correct as it happens in all versions of TB.

With the following should I be checking to see if the bug comes back in 102.15 (where it seemed to take some time - a few days) or could I check in 115.3.2 where I noticed it quite quickly - a few hours.

From there, after a period of days see whether the incorrect behavior comes back.

I have used mozregression before but it is not the easiest when flicking back and forth to recheck different builds.

Flags: needinfo?(steve)

All, Just to be clear, anyone can help by using mozregression, not just reporter

I have used mozregression before but it is not the easiest when flicking back and forth to recheck different builds.

Are you using a test profile? Please explain in more detail?

I am using my normal profile. mozregression works quite logically but sometimes a little human insight can speed things up. I am also not sure if this is one or 2 bugs, i.e. failing to indicate new mail when there is new mail has a different cause from indicating new mail when there is no new mail. The former (failing to indicate new mail when there is new mail) is far more prevalent.
With mozregression there is no "maybe" response. With this bug a "positive" can sometimes take 5 minutes (last check with 119) or longer and a confident negative 5 days so I was hopping about dailies looking only for the quick positives rather than persevering with the long negatives until I narrowed down the date range.

two bugs is certainly a possibility

Reporter Steve Edmonds,
Not sure if you are still seeing this issue. If so, after I read through the comments I'm not really sure I understand what the problem is. Assuming comment 0 still describes the problem, let me ask some questions:

(In reply to Steve Edmonds from comment #0)

Steps to reproduce:

A. Observed new message indicator in folder pane
Clicked on folder to check new messages

What are you seeing as a "new message indicator"? Do you mean a new message has arrived in a folder? I think you (or the other Steve) said everything works OK for Inbox and the problems are with other non-Inbox folders. If it's just non-inbox folders with the issue, how are "new" messages delivered to those folders -- tb filters, server side filters or some other way?

B. Observed new message indicator in folder pane
Clicked on folder to check new messages

When there is a new message you should see the account name go to blue and the folder containing the message go to blue with an orange "dot" or diamond on the folder icon and the folder unread count (in a circle with a black background) should increment.
Another relevant question is if the folder with the new message is deeply nested and possibly collapsed so it's not visible. With 102 and earlier, you will see the new message indication on the top level folder even if the folder with the new message is hidden due to being collapsed. With 115, currently you won't see the new message indication on the hidden folder on the top level folder as described in bug 1858388 (see attached video at that bug).

C. Observed NO new message indicator in folder pane
Clicked on folder to check new for messages

Actual results:

A. No new messages.

So the folder showed a new mail indication but when you open the folder you see no new messages there? How are you telling when a message is "new"? A new message will have the "recent" indicator (an orange diamond) and it will be bold in the message list since it is unread. If you see no new message(s) you can re-order the messages by adding a sort column "Order Received" and sort on that. The messages that are newest will have the highest "order received" number. It's possible that the "new" message has a date that is older than the current date so that the "new" message is not initially visible.

B. New messages had arrived, subject in bold but no new message indicator to the left.

A new and/or unread message will show more than just the "subject" as bold. All the fields shown for the message should be bold (which is probably what you mean). Again, probably unlikely, but maybe the new message indicator (the orange diamond/dot) is not in view and sorting by "order received" may reveal the "new" message.
Also, just to point out, once you visit a folder containing messages with the new message indicator (orange thing), then visit another folder and come back to that folder, the orange thing on each new message will be automatically removed (but the "new" message will remain marked unread/bold).

C. New messages were indicated in the message list of the folder

So the folder has no blue highlights and no orange thing on its icon. You open the folder and you see message(s) marked with the orange icon and also, I assume, with all fields bold? I have no idea about this if it occurs unless maybe you are accessing the same imap account with another client and it is causing some changes.

Anyhow, if you are still seeing the issues maybe you could re-summarize what the problem is. A screen shot or even a video capture, if it's possible to reproduce the issue, might also be helpful rather than just a verbal description.
Thanks!

I am still seeing this issue, I just have not had time to locate it in the dailies if the 102 line at the moment, I will try an interleaved reply.

(In reply to gene smith from comment #40)

Reporter Steve Edmonds,
Not sure if you are still seeing this issue. If so, after I read through the comments I'm not really sure I understand what the problem is. Assuming comment 0 still describes the problem, let me ask some questions:

(In reply to Steve Edmonds from comment #0)

Steps to reproduce:

A. Observed new message indicator in folder pane
Clicked on folder to check new messages

What are you seeing as a "new message indicator"? Do you mean a new message has arrived in a folder? I think you (or the other Steve) said everything works OK for Inbox and the problems are with other non-Inbox folders. If it's just non-inbox folders with the issue, how are "new" messages delivered to those folders -- tb filters, server side filters or some other way?

When working correctly the colour of the text of the name on a folder changes and a yellow dot appears on the folder icon to indicate a new message. In the message pane a yellow blob appears before the message subject to indicate it is a new message. All accounts are Gmail, all folders are labels applied in Gmail, the connection to Gmail is IMAP.

B. Observed new message indicator in folder pane
Clicked on folder to check new messages

When there is a new message you should see the account name go to blue and the folder containing the message go to blue with an orange "dot" or diamond on the folder icon and the folder unread count (in a circle with a black background) should increment.
Another relevant question is if the folder with the new message is deeply nested and possibly collapsed so it's not visible. With 102 and earlier, you will see the new message indication on the top level folder even if the folder with the new message is hidden due to being collapsed. With 115, currently you won't see the new message indication on the hidden folder on the top level folder as described in bug 1858388 (see attached video at that bug).

Folders are all visible and not nested.

C. Observed NO new message indicator in folder pane
Clicked on folder to check new for messages

Actual results:

A. No new messages.

So the folder showed a new mail indication but when you open the folder you see no new messages there? How are you telling when a message is "new"? A new message will have the "recent" indicator (an orange diamond) and it will be bold in the message list since it is unread. If you see no new message(s) you can re-order the messages by adding a sort column "Order Received" and sort on that. The messages that are newest will have the highest "order received" number. It's possible that the "new" message has a date that is older than the current date so that the "new" message is not initially visible.

Correct, the folder showed a new mail indication but when you open the folder you see no new messages there. This occurs much less frequently than C.

B. New messages had arrived, subject in bold but no new message indicator to the left.

A new and/or unread message will show more than just the "subject" as bold. All the fields shown for the message should be bold (which is probably what you mean). Again, probably unlikely, but maybe the new message indicator (the orange diamond/dot) is not in view and sorting by "order received" may reveal the "new" message.
Also, just to point out, once you visit a folder containing messages with the new message indicator (orange thing), then visit another folder and come back to that folder, the orange thing on each new message will be automatically removed (but the "new" message will remain marked unread/bold).

I understand, here the line is bold indicating the message is unread, but the orange diamond is not present indicating the message is new.

C. New messages were indicated in the message list of the folder

So the folder has no blue highlights and no orange thing on its icon. You open the folder and you see message(s) marked with the orange icon and also, I assume, with all fields bold? I have no idea about this if it occurs unless maybe you are accessing the same imap account with another client and it is causing some changes.

The above is correct and this is the most common meaning I have to regularly click through all folders. What ever is the cause, it is not present in 102.13 but is in 102.15 and everything after around 111.

Anyhow, if you are still seeing the issues maybe you could re-summarize what the problem is. A screen shot or even a video capture, if it's possible to reproduce the issue, might also be helpful rather than just a verbal description.
Thanks!
Are there 2 processes resulting in indication of new mail, i.e. checking for new mail at the account server setting and some sort of push notification from the email server. I notice with 102.13 I can send a new message and it is indicated in the receiving account within a few seconds when the receiving folder is selected or not. In 102.15 and 111 on it is variable and may not be indicated at all on the receiving folder when the receiving folder is not selected.
Inbox always indicates correctly. It is almost as though TB gets interrupted or runs out of time while checking so doesn't complete.

In TB 102.12 when a message is marked as "read" the font changes to normal while other unread messages remain bold. It has been this way for innumerable releases.
It remained this way through release 110b4 (no problem) until 111b1 Build 1 when the problem appeared.
The font does not revert to normal even when the message is marked as read.
The heading "unread" in the list in the Inbox disappears after two seconds (the length of time I selected in Settings) but the font stays marked as bold.
The issue has remained through 120b4.
This issue exists in all folders - trash, spam etc.
I've uninstalled / reinstalled - all manner of things.
No joy,
I've now, grudgingly, accepted this as per design and is now a permanent feature of TB.

(In reply to Steve Edmonds from comment #41)

Are there 2 processes resulting in indication of new mail, i.e. checking for new mail at the account server setting and some sort of push notification from the email server. I notice with 102.13 I can send a new message and it is indicated in the receiving account within a few seconds when the receiving folder is selected or not. In 102.15 and 111 on it is variable and may not be indicated at all on the receiving folder when the receiving folder is not selected.
Inbox always indicates correctly. It is almost as though TB gets interrupted or runs out of time while checking so doesn't complete.

Ok, thanks for the info. However, I don't think you answered how the messages are arriving in the gmail non-inbox folders. Probably doesn't matter but I'll just assume you have setup a filter at gmail site and gmail is dropping the messages there (and not into inbox).
Anyhow, I'm not sure if this has been mentioned in previous discussion on the bug, but to ensure messages are detected in non-inbox folder you need to set the right-click property for the folder so that new mail is checked there. So make sure the property item When getting new messages for this account, always check this folder is enabled/checked. Also, unless you frequently open/visit these non-inbox folders that receive new mail the "push" feature (actually imap IDLE) won't instantly detect new mail there either. So you also need to set the timer to to check for new mail to ensure new mail is always detected in non-inbox folders (timer is in server settings). Inbox doesn't have this issue since it is always imap selected as long as your new mail timer is set to 30 minutes or less.
If you change any of these setting in an attempt to resolve the issues, I would recommend restarting TB to make sure they take effect.
I don't know of any network changes between 102.13-15 that would affect this. Changes at 111 were mostly UI tweaks (called supernova).

(In reply to Steve from comment #42)

In TB 102.12 when a message is marked as "read" the font changes to normal while other unread messages remain bold. It has been this way for innumerable releases.

Correct.

It remained this way through release 110b4 (no problem) until 111b1 Build 1 when the problem appeared.
The font does not revert to normal even when the message is marked as read.

I'm not seeing this. I can right-click a message and mark it "read" in it goes to normal font. I only run, for the most part, self-built dailies and have never seen this as the versions have progressed. I'm at daily 121 right now and font goes to normal when it I manually mark the message read. (I don't use the automatic mark as read on message access feature.)

The heading "unread" in the list in the Inbox disappears after two seconds (the length of time I selected in Settings) but the font stays marked as bold.

I tried it with a 2 sec. timer and it seems to work correctly for me (font goes from bold to normal after having unread message open for 2 seconds). I'm not sure what you mean by heading "unread". The unread count in the "badge" beside Inbox in the folder pane does down by one when the message becomes un-bold..

I've now, grudgingly, accepted this as per design and is now a permanent feature of TB.

If you're seeing this, it's a bug. But I'm not seeing it here.

(In reply to Steve Edmonds from comment #30)

Another observation is that in 111.0b1 "Get all new messages" doesn't check all folders, many of the folders that are labels in Gmail accounts are not checked, or if they are new mail is not indicated until you click into the folder.

How are you knowing if they are checked or not?

I think you said above you have 169 folders on the gmail account. Are you expecting to receive new mail in all of these folder or just a few of them? If all of them, that will put quite a load on the system if you have pref mail.server.default.check_all_folders_for_new set to true. If that pref is false, then you need to set the property on individual folders that receive new mail so they are checked by the "get messages" click or by the timer.

What is your check for messages timer set to? (I think it defaults to 5 minutes.)
Also, I assume you have "immediate server notifications" turned on. That's what you call "push" but it actually just enables imap IDLE for the server. Again, IDLE only really works reliably on Inbox so you still need to poll for new mail using the timer if you are expecting new mail into non-inbox folders and you have to set the folder property so it is checked for new mail.

(In reply to gene smith from comment #43)
Just to clarify, I use the same profile when comparing 102.13 and 102.15/111+ so all the settings remain the same.

(In reply to Steve Edmonds from comment #41)

Are there 2 processes resulting in indication of new mail, i.e. checking for new mail at the account server setting and some sort of push notification from the email server. I notice with 102.13 I can send a new message and it is indicated in the receiving account within a few seconds when the receiving folder is selected or not. In 102.15 and 111 on it is variable and may not be indicated at all on the receiving folder when the receiving folder is not selected.
Inbox always indicates correctly. It is almost as though TB gets interrupted or runs out of time while checking so doesn't complete.

Ok, thanks for the info. However, I don't think you answered how the messages are arriving in the gmail non-inbox folders. Probably doesn't matter but I'll just assume you have setup a filter at gmail site and gmail is dropping the messages there (and not into inbox).
Anyhow, I'm not sure if this has been mentioned in previous discussion on the bug, but to ensure messages are detected in non-inbox folder you need to set the right-click property for the folder so that new mail is checked there. So make sure the property item When getting new messages for this account, always check this folder is enabled/checked.
I have tried this, the setting When getting new messages for this account, always check this folder seems to make little difference. Folders with this checked can fail to indicate new mail and folders without this checked regularly indicate new mail.
Also, unless you frequently open/visit these non-inbox folders that receive new mail the "push" feature (actually imap IDLE) won't instantly detect new mail there either.
My check for new mail interval is 10 minutes. I am observing that 102.12/13 always, within a short time (<1 minute), indicates new mail in any folder. 102.15, 111+ doesn't
So you also need to set the timer to to check for new mail to ensure new mail is always detected in non-inbox folders (timer is in server settings). Inbox doesn't have this issue since it is always imap selected as long as your new mail timer is set to 30 minutes or less.
As stated, this is set to 10 minutes and new mail still fails to be indicated. For example (on 102.15) this morning my TB folder shows no indication of new mail but clicking on the folder at 08:20 I have 3 new emails 00.00, 07:25, 07:45.
If you change any of these setting in an attempt to resolve the issues, I would recommend restarting TB to make sure they take effect.
I don't know of any network changes between 102.13-15 that would affect this. Changes at 111 were mostly UI tweaks (called supernova).
I don't believe this is necessarily a network issue but possibly a UI failing to be updated issue.
I notice that 102.13 starts 2 child processes, -childID 1 and -childID 2 and 102.15 starts only -childID 1 so whether those changes have resulted in this behaviour.

(In reply to gene smith from comment #45)

(In reply to Steve Edmonds from comment #30)

Sorry, mucked up the markdown previously

Another observation is that in 111.0b1 "Get all new messages" doesn't check all folders, many of the folders that are labels in Gmail accounts are not checked, or if they are new mail is not indicated until you click into the folder.

How are you knowing if they are checked or not?

I can only tell for sure if the folder fails to indicate new mail. When clicking on the folder I can see the time of the messages to know that new mail should have been indicated.

I think you said above you have 169 folders on the gmail account. Are you expecting to receive new mail in all of these folder or just a few of them? If all of them, that will put quite a load on the system if you have pref mail.server.default.check_all_folders_for_new set to true. If that pref is false, then you need to set the property on individual folders that receive new mail so they are checked by the "get messages" click or by the timer.

The 169 folders are spread over multiple accounts. Some rarely get new mail, may be 25 or so regularly get new mail. mail.server.default.check_all_folders_for_new is set to true.

What is your check for messages timer set to? (I think it defaults to 5 minutes.)

10 minutes

Also, I assume you have "immediate server notifications" turned on. That's what you call "push" but it actually just enables imap IDLE for the server. Again, IDLE only really works reliably on Inbox so you still need to poll for new mail using the timer if you are expecting new mail into non-inbox folders and you have to set the folder property so it is checked for new mail.

I have have "immediate server notifications" turned on, IDLE only works reliably in 102.13

Yes, after I asked about the 169 I re-read your comment above and saw they are spread over 7 accounts.

mail.server.default.check_all_folders_for_new is set to true.

That should work but every 10 minutes, as your timer is set, it will have to go through all 169 folder and do an IMAP status on each of them. But it might be "more efficient" and produce less cpu and network load if you set "check_all_folders_for_new" to false and explicitly set which folders you want checked using the setting in each folder's properties. Then it would only have to check status on 25 folders every 10m.

I can only tell for sure if the folder fails to indicate new mail. When clicking on the folder I can see the time of the messages to know that new mail should have been indicated.

Ok, maybe we need a more low-level check to see what's going on and why new mail is not detected. This will require recording an IMAP:4 log to see what's happening.

You're on linux like I am so you should be able to capture the log just by running tb from a bash command line in a terminal, for example, like this:

$ MOZ_LOG=IMAP:4,timestamp,sync  MOZ_LOG_FILE=~/tblog  thunderbird -p --allow-downgrade

This will put the log file in home dir (you can put it anywhere) with file name tblog.moz_log (you can change tblog to anything) and run your installed TB. You may need to add the full path to thunderbird if it's not on your $PATH.
Or, alternatively, you can just follow the instruction shown here: https://wiki.mozilla.org/MailNews:Logging for linux.

Since you have 7 accounts, to make the log readable it would be good to only record the log for the account most likely to show the problem and "disable" all the rest. To disable the accounts, in server setting, de-select 2 items:
Check for new mail at startup
Check for new mail every X min

Then run tb using the command line above. The -p allows you to select a profile so you might not need this if you always run the same profile. The --allow-downgrade lets you fall back to older versions without creating a new profile (works ok with 115 downgraded to 102).
Once it starts, don't select any folders on the "disabled" accounts since that will still cause them to be accessed via imap and clutter the log.

You also might want to lower the new mail check timer on the single enabled account down to a shorter value (maybe the minimum 1 minute) so you don't have to wait 10 minutes for mail polling.

You can watch the log while it's recording and you should see every minute (or 10 minutes) that an imap STATUS command is done on each folder (or on the selected folders if you use the property setting instead of the pref to check every folder). But any folder that is imap SELECTed, you will see a imap NOOP sent to it to detect new messages.

Anyhow, if you could record the log and attach it above or email it to me, it might tell us something.

I have have "immediate server notifications" turned on, IDLE only works reliably in 102.13

IDLE seems to be working for me when I test it. But maybe your log will show something that I'm missing.
But again, IDLE only really works "reliably" for Inbox since it's almost always in the imap SELECTed state. It will have no effect on other folders unless they are also SELECTed (recently visted or new mail was recently detected). So if you have a lot of non-imap folders to check, polling (via imap STATUS) is going to occur on the timed interval.

This brings up another question, in server "advanced" setting, is everything there at default setting, especially the number of cached connection (default 5)?

Flags: needinfo?(steve)

I have been running 115.5.0 (64-bit) for a few weeks from openSUSE repository and the issue seems to have diminished to some degree or the behaviour is slightly different and less prominent (I am not missing seeing new emails regularly). Possibly the issue has gone away. When I get a chance I will check the latest beta.
Could the packaging, files or build be different between the version provided by openSUSE and from archive.mozilla.org/

Flags: needinfo?(steve)

(In reply to Steve Edmonds from comment #49)

I have been running 115.5.0 (64-bit) for a few weeks from openSUSE repository and the issue seems to have diminished to some degree or the behaviour is slightly different and less prominent (I am not missing seeing new emails regularly). Possibly the issue has gone away. When I get a chance I will check the latest beta.

What did you find?

Could the packaging, files or build be different between the version provided by openSUSE and from archive.mozilla.org/

Not such that it would affect message display.

Flags: needinfo?(steve)
You need to log in before you can comment on or make changes to this bug.