1847137 - 115.1 hangs randomly "not responding" when automatically checking multiple accounts for new messages. Workaround stagger mail check interval

Status: RESOLVED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[Joseph]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

I have removed all add-ons, deleted all msf files, disabled the indexing, rebuilt mailboxes, and redid the shift install option and it freezes randomly.

Actual results:

Freezes without crashing and mainly freezes now in message composition boxes but will freeze when I leave it open and do something else then come back to TB.
Also, the indexing seemed to keep running continuously, but I turned that Off.

Expected results:

This started happening in the last release 115.1 It did not happen before. I even ran in administrator mode, but that did not help. I cleaned up and compacted all emails, tool.

Comment 1

[dk]

The same problem. Thunderbird works very slow. I thought about a big email directory, but I have only about 2gb of emails, so it should [not] be a problem.

The version 115.1.1

Comment 2

[John]

Similar or same problem, it started after the update to v115 on Windows and was not fixed by updates. Current version: 115.2.0 (64-bit).

Thunderbird v115 is indeed slower than the previous version.

Starting in troubleshooting mode seems to extend the time until the next hang. No plugins are currently active. enigmail/gpg is configured.

The Thunderbird process has to be killed in task manager as the program is greyed out and not responding. The process does not use cpu at that time (0%). Thunderbird may be waiting for something that will never happen in a blocking mode.

I would suggest to make network requests non-blocking at network programming level and check what happens when there are network issues. Check for follow ups on network traffic that assume that there will not be a network problem. That may also be a way to reproduce the problem.

Also, check for waits without a timeout.

Is there anything I can do to trace what Thunderbird is doing? The problem is not immediate and may take hours, so I need something that will trace and log.

Comment 3

[cpohle]

Similar or same problem, it started after the update to v115

I can confirm a massive performance loss since the update to v115, rendering e-mail composition sometimes virtually impossible.

Maybe bug #1844842 is related, see my performance report on https://share.firefox.dev/43Vgw8p

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to John from comment #2)

Is there anything I can do to trace what Thunderbird is doing? The problem is not immediate and may take hours, so I need something that will trace and log.

ALL, Please obtain a performance profile and post the link here. THanks. https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance

Comment 5

[John]

Thunderbird has no permission to open http links. These are blocked for security and privacy reasons.

I'll need local debugging. Where is debug/log data stored locally?

Comment 6

[John]

Also, collected data should be saved immediately, e.g. written to disk. When Thunderbird hangs it won't be able to collect or show anything because it's unresponsive.

There may be a correlation with network traffic. Background traffic to http sites may trigger or induce the hanging problem.

If so, it may be possible to reproduce by changing http in urls to xhttp. about:config, search for http and prepend x to all links found.
That will invalidate the link because Thunderbird will not know what application to use to open such a link. A Window pops up asking for the program. Leave it untouched, after a while (may be hours) it would hang.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Joseph from comment #0)

This started happening in the last release 115.1 It did not happen before.

Most of the fixes in 115.1.0 were UI related https://mzl.la/486KTfs.
That said, if it really did start with 115.1.0 it would greatly help to confirm the immediate prior version did not have the problem.
Download 115.0.1 from https://archive.mozilla.org/pub/thunderbird/releases/115.0.1/win64/en-US/ and install it OVER TOP of 115.1.0, in the SAME program directory.

(In reply to dk from comment #1)

The version 115.1.1

Most of the fixes in 115.1.1 were UI related https://mzl.la/3Ew3Zy0.
That said, if it really did start with 115.1.1 it would greatly help to confirm the immediate prior version did not have the problem.
Download 115.1.0 from https://archive.mozilla.org/pub/thunderbird/releases/115.1.0/win64/en-US/ and install it OVER TOP of 115.1.1, in the SAME program directory.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to John from comment #2)

Similar or same problem, it started after the update to v115 on Windows and was not fixed by updates. Current version: 115.2.0 (64-bit).

Update from what?

Thunderbird v115 is indeed slower than the previous version.

Starting in troubleshooting mode seems to extend the time until the next hang. No plugins are currently active. enigmail/gpg is configured.

Thanks for those tests and details. A stronger test is start Windows in safe mode.

• Please start Windows in safe mode with networking enabled https://support.microsoft.com/en-us/help/12376/windows-10-start-your-pc-in-safe-mode
• Still in Windows safe mode, start Thunderbird in Troubleshoot mode https://support.mozilla.org/en-US/kb/troubleshoot-mode-thunderbird

Does problem go away?

The Thunderbird process has to be killed in task manager as the program is greyed out and not responding. The process does not use cpu at that time (0%). Thunderbird may be waiting for something that will never happen in a blocking mode.

Without some smoking gun pointing conclusively to network I seriously doubt that is the cause.

Comment 9

[Joseph]

I think that Thunderbird hangs on connection. So, I am going to disable all automatic get mail functions and see if that helps.

Comment 10

[John]

Update from what?

From the last version before v115. The download from the official site and the update were performed manually. Automatic updates are disabled by policy.

Thanks for those tests and details. A stronger test is start Windows in safe mode.

• Please start Windows in safe mode with networking enabled https://support.microsoft.com/en-us/help/12376/windows-10-start-your-pc-in-safe-mode
• Still in Windows safe mode, start Thunderbird in Troubleshoot mode https://support.mozilla.org/en-US/kb/troubleshoot-mode-thunderbird

Does problem go away?

Thanks, but no, it doesn't. It still hangs. There is no change except for visuals (no greying in svga mode due to unresponsiveness). As said, troubleshoot mode does not prevent it, it may delay it somewhat because there may be less background http traffic. There are no plugins active. No antivirus or anything else that would hook Thunderbird is active. The system has few third party background processes running.

Without some smoking gun pointing conclusively to network I seriously doubt that is the cause.

Trigger or cause is unknown at this point, but it is a reasonable suspicion. The hang often occurs when a xhttp link opening window is shown as described. It is not immediate, it may take hours to a day. Suggested method to reproduce in comment 6. Try this for a few days, not shutting a window popping up, and see it it doesn't cause hanging problems.

Perhaps an open protocol/application selection window blocks the next protocol/application window, which would possibly cause the program to hang? e.g. something blocking a thread that the main program is waiting for. Blocking I/O, threading or network requests are suspects when programs hang.

Comment 11

[Joseph]

The problem stopped when I disabled the automatic periodic polling of email addresses and only got messages at startup or upon specific request. This is the latest 115.2.1 (64-bit) version. In some way, getting messages running in the background as short as 2m causes Thunderbird to lock up and hang. This then requires closing and reopening the program.

Comment 12

[John]

(In reply to Joseph from comment #11)
Thunderbird 102 had pop3 email retrieval stall when there were local network problems. See bug 1779306 (method to reproduce, fix). It did not cause a hang though.

Comment 13

[Joseph]

I made it so that it only pulled down new emails at the beginning when the program started or upon specific requests. Before I had multiple emails that would pull down new emails in as little as two minutes. Since I no longer have an automatic download of my new emails, the problem has stopped and has not occurred in anyway. There is some thing about setting automatic emails to pull down in the background That is triggering the hang I’m not sure if one request for one email occurs the same time as the other email and then they have some type of a “Collision“ that causes the system to hang. I will go back and set all my emails to pull down in one minute and I bet this will cause a problem to reoccur . But I will have to report back as to whether this is true as I think I’m running 15.3.1 now I don’t see any release notes to indicate the problem has been fixed and it still is open in this formula.

Comment 14

[Wayne Mery (:wsmwk)]

With no solid leads, perhaps the best way to find the cause is find the regression range using https://mozilla.github.io/mozregression/ - it will do most of the work for you.

Comment 15

[cpohle]

After throwing away my legacy TB profile (actually the whole ~/Library/Thunderbird folder under macOS) and starting over with a fresh setup using TB 115.3.2. TB runs snappy like hell now compared to before. I guess there was some leftover configuration option from the past decade that caused the performance problems.

(In reply to cpohle from comment #3)

Similar or same problem, it started after the update to v115

I can confirm a massive performance loss since the update to v115, rendering e-mail composition sometimes virtually impossible.

Maybe bug #1844842 is related, see my performance report on https://share.firefox.dev/43Vgw8p

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to Joseph from comment #13)

I made it so that it only pulled down new emails at the beginning when the program started or upon specific requests. Before I had multiple emails that would pull down new emails in as little as two minutes. Since I no longer have an automatic download of my new emails, the problem has stopped and has not occurred in anyway.

You are using imap?
In setting the mail check interval, at what value of minutes (starting at 10 for example) do you start seeing a problem

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to John from comment #2)

Similar or same problem, it started after the update to v115 on Windows and was not fixed by updates. Current version: 115.2.0 (64-bit).

I'm beginning to doubt your issue is the same, or at least it isn't so far helping this bug report reach a resolution. I think it's actually getting a little confusing mixing the two [two different reporters]. So please file a new bug report - if after 115.4.1 (coming out in a week or two) you still have a problem which reproduces in WIndows safe mode

Comment 18

[Joseph]

I went back and set the download times not be the same for the different email accounts. It does not appear to be hanging now.
I’m not sure if this was the problem but if numerous accounts reset to download at the same number of minutes, it may cause it. Generally speaking, I said everything to about 10 minutes and I’m not sure what the program does, but it may try to pull all of them down at the same time.

Comment 19

[kent-mozilla]

These lags are a show-stopper. The forced unnecessary changes to the user interface were awful, but the lags when checking for the new messages are unacceptable.

I do not have time to beta test 115, and the impracticality of 115 almost seems like a conspiratorial move by competitors posing as developers to drive the development of Thunderbird into oblivion.

To resolve this issue with lags, I've reverted 115 to 102. I now have a new respect for 102. Thunderbird 102 is much faster, has no lags, has a simple, understandable interface, and does not require months of learning to understand.

There was never a need to change Thunderbird UI, and certainly not any reason to push all Thunderbird users to beta test this buggy, unfamiliar new version.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Joseph from comment #18)

I went back and set the download times not be the same for the different email accounts. It does not appear to be hanging now.
I’m not sure if this was the problem but if numerous accounts reset to download at the same number of minutes, it may cause it. Generally speaking, I said everything to about 10 minutes and I’m not sure what the program does, but it may try to pull all of them down at the same time.

Thanks for that info.

Had you tested in Windows safe mode?

Comment 21

[Joseph]

No I did not test in safe mode. Changing the email download times and making them different worked. At first I eliminated them and only downloaded at startup which also worked. This problem may not occur if you do a clean install of 115 based on another bug report and that person also said no slowdown. Thus, it appears that the problem is due to the update to 115 from the previous last version.

Comment 22

[John]

Attachment: tb115.3.3_process_monitor.xml

As mentioned earlier, the problem started when updating to v115 for my case too.

I have run Sysinternals Process Monitor 3.96. It shows that when Thunderbird becomes unresponsive, imaps requests continue in the background and thread creation/exit continues. Pop3 requests stop completely.

In this instance, Thunderbird runs using 3 processes:
3860 - main process
9116
15060

Processes 3860 and 9116 continue to create and exit threads.

Notes:
"home" means a local redirect through a tunnel
WSNAME is the name of the Windows workstation
OS: WIndows 11 latest, no antivirus running
Path letters were replaced. The install has no windows or user data on C:
Host names were replaced.
Replaced various port numbers to 12345, 12346 and 12347.

Comment 23

[John]

Attachment: tb115.3.3_process_monitor.xml reupload

Reupload as binary due to Bugzilla complaining about XML structure. Inserted a XML header too.

Comment 24

[John]

Attachment: tb115.3.3_process_monitor2.xml - now with headers

Comment 25

[John]

Updated tot v115.4.0. It shows a crash message after running for some time. May be unrelated.

Some analysis shows null pointer access violation in xul.dll.
0xC0000005: Access violation reading location 0x0000000000000000

Are there symbols and .pdb available for Thunderbird?

Comment 26

[Wayne Mery (:wsmwk)]

(In reply to John from comment #25)

Updated tot v115.4.0. It shows a crash message after running for some time. May be unrelated.

Please file a new bug and we can continue there.

Comment 27

[John]

Please file a new bug and we can continue there.

bug 1861448

Comment 28

[Wayne Mery (:wsmwk)]

dk, captain,

Using config editor try setting mail.db.max_open and mail.db.idle_limit to larger values. For example doubled.

Comment 29

[Wayne Mery (:wsmwk)]

Joseph,
dk,
This did not happen for you in version 102?

Can you find the regression range? It would be very helpful. https://mozilla.github.io/mozregression/

Comment 30

[EarlgreyTea]

(In reply to Wayne Mery (:wsmwk) from comment #29)

Joseph,
dk,
This did not happen for you in version 102?

Can you find the regression range? It would be very helpful. https://mozilla.github.io/mozregression/

There have been several reports of similar issues on the MozillaZine.jp forum, and I asked one of them to check the regression range using mozregression.
May I comment here?

Comment 31

[EarlgreyTea]

Several problems similar to this bug have been reported on the MozillaZine.jp forum, one of which I would like to report.

• After running Thunderbird 115 for a while with POP accounts set to automatically check email, it randomly hangs.
• In this case, Thunderbird will not return to normal unless terminated using the Windows Task Manager.
• In offline mode Thunderbird does not hang after several hours.
• Thunderbird has only POP accounts, no IMAP.
• No unified folders.
• Global search indexing is disabled.
• The forum reporter runs both Thunderbird 102 and 115 on the same Windows 11 PC, but 102 never hangs.

I asked the forum reporter to check the regression range with mozregression.

(first bad build)
build_date: 2023-05-17 17:56:29.989000
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=2002b47e052545e44375944bfb1108cadc2f3fbb&tochange=f95afff61536c4067763f9df8cc5ecb31592b821

Comment 32

[Wayne Mery (:wsmwk)]

Thanks for the regression range!
I wonder if the issue is from mozilla-central
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2023-05-16+8%3A00%3A00&enddate=2023-05-17+17%3A20%3A00

Magnus, does anything stand out for you?

Comment 33

[Joseph]

This bug did not appear in version 102, but it did appear immediately after the update to 115
As I mentioned before for me, The fix was to put longer delays and stagger them, when when emails were automatically downloaded
this change still works but I did not find anything else in terms of repairs or compacting or redoing the email database or setting other perimeters that avoided the hang. 115 still seems to run fairly slow, but to fix that I believe I have to just uninstall everything and reinstall the entire latest version.

Comment 34

[Magnus Melin [:mkmelin]]

Unfortunately nothing stands out, and there's a lot of commits there.

Comment 35

[EarlgreyTea]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Unfortunately nothing stands out, and there's a lot of commits there.

Should people who report Thunderbird hang need to gather additional information or test?
Are you considering a test build for that (e.g. output special logs or crash when it detects a hang)?

Comment 36

[Wayne Mery (:wsmwk)]

(In reply to Joseph from comment #33)

This bug did not appear in version 102, but it did appear immediately after the update to 115
As I mentioned before for me, The fix was to put longer delays and stagger them, when when emails were automatically downloaded
this change still works but I did not find anything else in terms of repairs or compacting or redoing the email database or setting other perimeters that avoided the hang. 115 still seems to run fairly slow, but to fix that I believe I have to just uninstall everything and reinstall the entire latest version.

Joseph, does setting mail.db.max_open and mail.db.idle_limit to larger values help? Double or 10x. With non-staggered mail checks.

Comment 37

[EarlgreyTea]

(In reply to EarlgreyTea from comment #31)

Several problems similar to this bug have been reported on the MozillaZine.jp forum, one of which I would like to report.

A follow-up report on this matter is now available on the MozillaZine.jp forum.
According to the report, it improved after changing the connection security from "STARTTLS" to "SSL/TLS".
From this, it can be inferred that there may be some problem when the connection security is "STARTTLS".

Comment 38

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Unfortunately nothing stands out, and there's a lot of commits there.

FWIW In that time range is Bug 1830979 - Reduce number of rows rendered in scroll event

Comment 39

[Wayne Mery (:wsmwk)]

(In reply to EarlgreyTea from comment #37)

(In reply to EarlgreyTea from comment #31)

Several problems similar to this bug have been reported on the MozillaZine.jp forum, one of which I would like to report.

A follow-up report on this matter is now available on the MozillaZine.jp forum.
According to the report, it improved after changing the connection security from "STARTTLS" to "SSL/TLS".
From this, it can be inferred that there may be some problem when the connection security is "STARTTLS".

Have there been any follow up postings? Or you have additional information?
Can you cite the URL to the posting?

Comment 40

[EarlgreyTea]

(In reply to Wayne Mery (:wsmwk) from comment #39)

Have there been any follow up postings? Or you have additional information?
Can you cite the URL to the posting?

The topic is below:
MozillaZine.jp フォーラム • トピック - Ver.115系で「応答なし」が回避できたケース
(A case where "Not Responding" could be avoided with Ver.115 series)

Comment 41

[gene smith]

(In reply to Wayne Mery (:wsmwk) from comment #38)

(In reply to Magnus Melin [:mkmelin] from comment #34)

Unfortunately nothing stands out, and there's a lot of commits there.

FWIW In that time range is Bug 1830979 - Reduce number of rows rendered in scroll event

As described here (bug 1875633 comment 65), with supernova versions (>=115) I can greatly slow down POP3 processing by scrolling the message list with mouse wheel and completely stop it by grabbing the scroll bar and moving the list up and down continuously.
But these scroll actions have no effect on POP3 activity with non-supernova (102) with the same JS POP3 code (or if deprecated C++ POP3 is enabled in 102).

Comment 42

[Wayne Mery (:wsmwk)]

Confirming based on multiple reports.

Joseph, are your accounts imap? Or pop?

And does the following comment 37 match your experience?

.(In reply to EarlgreyTea from comment #37)

(In reply to EarlgreyTea from comment #31)

Several problems similar to this bug have been reported on the MozillaZine.jp forum, one of which I would like to report.

A follow-up report on this matter is now available on the MozillaZine.jp forum.
According to the report, it improved after changing the connection security from "STARTTLS" to "SSL/TLS".
From this, it can be inferred that there may be some problem when the connection security is "STARTTLS".

Comment 43

[Joseph]

The emails were Pop

No they were already SSL/TTL

What fixed it was to stagger the automatic pull mail
Times which were all set to 10m for about 10 email boxes.

Varied the time mail was automatically pulled.

I think the email system in terms of viewing files by filters is still very slow
And I think that I would have to rebuild my Thunderbird with a clean build
Then load my email DB

Comment 44

[gene smith]

I have an experimental patch that I worked on a few weeks ago to "serialize" the pop3 accesses so that only one POP3 server access occurs at any given time. I haven't looked at it in a while but it might have an effect on this bug, considering that the reporter says staggering the times to check for new messages and downloading them has a positive effect.

Reporter Joseph, you may have already said somewhere above, but how many POP3 accounts do you have?

Re bug 1875633:
Isaac, I know you have a lot of POP3 accounts and you also stagger the times to check for new messages (but for a different reason than is described in this bug). Have you ever seen TB just lock up if you DON'T stagger the new mail check times?

Comment 45

[Isaac Ribeiro]

(In reply to gene smith from comment #44)

Isaac, I know you have a lot of POP3 accounts and you also stagger the times to check for new messages (but for a different reason than is described in this bug). Have you ever seen TB just lock up if you DON'T stagger the new mail check times?

Considering that I am reading your question now, I will perform this test tomorrow.

Comment 46

[gene smith]

From comment 44:

I have an experimental patch that I worked on a few weeks ago to "serialize" the pop3 accesses so that only one POP3 server access occurs at any given time.

I re-tested the patch and have applied it to 115.8.2 as a "try" build. The windows installer for it is here:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/dmH0aLIrQRuJSwVLj7PKwA/runs/0/artifacts/public/build/install/sea/target.installer.exe
Note that if you run this "Help/About TB" will show as "Daily" but the version will show 115.8.2.

I don't know if this will make a difference but if someone is willing to run this and see if it works any better WITHOUT staggered POP3 new mail check times, it might tell us something.
I have 3 POP3 accounts that are running at 1 check for new mail per minute and I haven't seen a freeze or lock up with or without this "serializing" patch.

FYI, here's the info on the "try" build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=81e34afca973ad00670e635f590a2628ce571719&selectedTaskRun=dmH0aLIrQRuJSwVLj7PKwA.0

From comment 45:

Considering that I am reading your question now, I will perform this test tomorrow.

Thanks, Isaac. It will be interesting what you see.
Also, Isaac, the installer link above does not include the changes made to fix your bug 1875633. So to do the test, just keep running what you are now running. Thanks again!

Comment 47

[Isaac Ribeiro]

(In reply to gene smith from comment #46)

Thanks, Isaac. It will be interesting what you see.
Also, Isaac, the installer link above does not include the changes made to fix your bug 1875633 comment #47. So to do the test, just keep running what you are now running. Thanks again!

I tested with 27 accounts at startup, 26 with AUTH2 authentication (Hotmail, Gmail, Yahoo etc.) and 1 with a normal password. Many accounts had new messages to download. There was no freezing or crashing.

By the way, I remember that TB would freeze when searching for new messages from the main account with builds later than the version I currently use. For this reason, I considered the version of bug 1875633 comment #47 to be the best.

Comment 49

[EarlgreyTea]

I asked for help testing using a "try" build on the MozillaZine.jp forum.
One person has already started testing.

Comment 50

[EarlgreyTea]

The "Try" build seem to have produced good results.
The user in the case described in comment #31 has tested it and said it did not hang up after a few days of running multiple POP accounts for 12 hours or more.
Setting two of the multiple POP accounts to STARTTLS did not cause any problems.

Comment 51

[gene smith]

The "Try" build seem to have produced good results.

Earl,
Probably dumb question but just want to make sure you that you are referring to the try build pointed to in comment 46?

Comment 52

[EarlgreyTea]

That's right.
A MozillaZine.jp user had good results with the following builds.

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/dmH0aLIrQRuJSwVLj7PKwA/runs/0/artifacts/public/build/install/sea/target.installer.exe

Comment 53

[Roger V.]

I, too, have had success with the try build referred to in comment 46; no crashes and no other unwanted behaviour as far as I can tell.

Comment 54

[gene smith]

Attachment: Bug 1847137 - Run POP3 accounts serially instead of in parallel. r=mkmelin

When a user has multiple POP3 accounts, instead of trying to run
them all at the same time, this causes them to be run sequentially
so that staggering the check for new message time is not needed
to avoid slow-downs/freezes.
This also changes the logging "prefix" to include the account's
server key (e.g., "server5") and the run number for the account to
make it possible to distinguish each account's logged entries. E.g.,
prefix is now "pop3.server5.22" (the 22nd run for server 5).

Comment 55

[gene smith]

I've updated for review the patch shown in comment 54 above. I've also made a "try" build containing the patch based on beta version 125.0b5.
Here's the direct link to the optimized win64 installer for the try build:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Smb08IjvT2y_Z0K3QMhTeA/runs/0/artifacts/public/build/install/sea/target.installer.exe

The other architecture builds (optimized and debug) are also available at the "try" site if anyone needs a non-windows64 version:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=2721d81a7164b03e0c0fa8f0133e7f05faac53d4&selectedTaskRun=Smb08IjvT2y_Z0K3QMhTeA.0
(Click the appropriate green "B" and look under "Artifacts and Debugging Tool" to find the installation file.)

Isaac, since you have probably most intensive POP3 usage I've ever seen with at least 27 accounts and lots of messages on servers, if you could run this build it would be most helpful. I've tested it extensively with 4 POP3 accounts with 2 accounts containing about 30k messages on server and it works correctly for me but this doesn't compare to the size of your POP3 setup.
Beta 125.0b5 also now contains the fixes for bug 1875633 so the "try" build will include those fixes as well (sending NOOP keepalives).
If you run the "try" build, the best test would be NOT to stagger your "check for new mail" times and set them all to the same time.
I know I asked you to do the same thing back at comment 44 with your current version, but this time it needs to be tested with this "try" build.
Thanks again!

Comment 56

[gene smith]

I've updated the patch at comment 54 again. I introduced a bug that causes "Get Selected Messages" menu item to not work -- this bug is in the try build of comment 55. It should only affect users who configure TB to "Fetch headers only" in server settings so if multiple messages are selected for download, it won't work. But downloading an individual message (using the link in the empty message body) will still work OK.
FYI, I commented out a function that appeared to be unused but is actually needed for the "Get Selected Messages" functionality.

I went ahead and updated the try build: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=2107d05260846645ae5df2e3e6c095ef0193c5cc

Here's the updated window64 installer for the new (bug free:)) build:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/e_x_wJy4QjyCewQjWYWZpg/runs/0/artifacts/public/build/install/sea/target.installer.exe

Again, this try build in based on beta 125.0b5.

Comment 57

[gene smith]

I don't know if anyone has ran either of the "try" builds above. Not that there is a functional problem with the try build referenced in comment 56, but the code review (linked to in comment 54) was not approved and I've been asked to make some changes to my method. So now there is no immediate need to run the try builds.
But if anyone has ran either build (in comment 56 or comment 55) I'd still appreciate knowing if it worked OK.

Comment 58

[EarlgreyTea]

I've only let it run for about an hour, but both builds (in comment 55 and comment 56) appear to be fine.

Comment 59

[Isaac Ribeiro]

TB worked very well with the build from comment #56. It started with 34 accounts at startup.

Comment 60

[gene smith]

Isacc, EarlgreyTea and Roger V,
Thanks for testing the build(s)!
I'm still tweaking the code some based on the code reviews by Magnus.

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/48d90ab39214
Run POP3 accounts serially instead of in parallel. r=mkmelin

Comment 62

[Wayne Mery (:wsmwk)]

This has been on beta nightly for two weeks, and as a serious 115 regression has potential for going to 115...

Comment 63

[Wayne Mery (:wsmwk)]

Comment on attachment 9395199 [details]
Bug 1847137 - Run POP3 accounts serially instead of in parallel. r=mkmelin

[Triage Comment]
Approved for beta - to get two more weeks of beta testing in advance of beta 128

Comment 64

[Wayne Mery (:wsmwk)]

Correction, I meant to say this has been on nightly for two weeks

Comment 65

[Daniel Darnell [:dandarnell]]

Thunderbird 127.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/0ad2ceb3425c