Steps to reproduce:

Sometimes thunderbird shows blank message pane for news messages after intermittent network problems. Unsure the steps below reproduces an annoying real life issue that I have seen many times with older thunderbird versions (68, 78, 91). Previously I mentioned this particular issue in the Bug #1753195 comment #28.

• Try to click on a couple of messages in some newsgroup to ensure that everything work (to be precise I had single connection to the NNTP server in ESTAB state at this moment)
• Add DROP firewall rule to simulate lost packages (not REJECT that results in immediate detection of failed server due to ICMP response)
• Try to click on more messages, e.g. "1", "2", "3", and "2" again
• Wait till network connections were lost at kernel level due to timeout. I checked it using ss -tnp command, at first another "SYN-SENT" connection appeared, after ~10 minutes both connections disappeared.
• Remove the firewall rule to simulate recovered connection
• Try the same "1", "2", and "3" messages.

Actual results:

Blank pane is displayed instead of messages accessed during the period on problems with network. It is possible to read other messages though.

Expected results:

Thunderbird retries fetching in the case of earlier failures, so messages are reliably displayed even at first the user clicked on them during problems with delivery of network packets.

Likely this issue is distinct from the case of server downtime (or REJECT firewall rule). see the Bug #1757904

Thunderbird retries fetching in the case of earlier failures, so messages are reliably displayed even at first the user clicked on them during problems with delivery of network packets.

By retries fetching here, you mean if you stay on one message, and if the connection timed out, TB starts a new connection automatically? I don't know if that's good.
When working on bug 1757904, I did realize a blank page is not instructive, a timeout error message with a reload button seems reasonable to me.

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

Thunderbird retries fetching in the case of earlier failures, so messages are reliably displayed even at first the user clicked on them during problems with delivery of network packets.

By retries fetching here, you mean if you stay on one message, and if the connection timed out, TB starts a new connection automatically? I don't know if that's good.

I tend to agree that thunderbird should not retry fetching of the message automatically. Let me clarify what I meant. With earlier versions of thunderbird (e.g. 68 and 78) I faced many times the following issue. If some transient network problem happened during fetching of a message (I suspected wifi adapter that sometimes does not wake up quickly enough or unable to recognize change of channel) then the message was displayed blank and such state sometimes persisted after restart. Switching to another message made things only worse, patience sometimes helped. Unsure concerning thunderbird-91 since I enabled offline caching and now I am suffering from other bugs. Such behavior I consider unreliable.

Thunderbird certainly should retry the message if I switch to another message and then back to the one had failure during the previous attempt.

Yesterday I tried 100.0a1 and the behavior was really terrible, Maybe it has changed during last couple of months. After ~20min with an active firewall DROP rule, so earlier opened connections reached timeouts at the kernel level, thunderbird did not start new connections at all even I clicked on messages that I have not try to read before. It was impossible to read any new message.

When working on bug 1757904, I did realize a blank page is not instructive, a timeout error message with a reload button seems reasonable to me.

Reload button or at least some text describing the problem is a bright idea. The only note: please, do not add animated indicators or progress bars, spinning images, bouncing balls, etc (Bug 1757544).

Actually thunderbird may show headers for another message and it is really confusing. The only worse thing I have seen earlier that you switch to another message, it appears on the screen but after some pause it is replaced by the one you tried earlier. Headers and body maybe out of sync in such cases.

max are you still seeing this issue?

This appared today - Bug 1827285 Thunderbird not displaying updates to Usenet after sitting idle

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

max are you still seeing this issue?

I have found some recipes how to minimize impact in daily usage. Fortunately it requires minimal effort, otherwise I would give up already and would switch to a more reliable mail user agent.

I just scratched the surface when I noticed this issue. I do not know if it is related to real issues and there is no point to go deeper (DNS, etc.) till obvious failures are fixed. My conclusion from the bug #1753195 is that nobody can deal with races in message fetching code.

I provided a clear and simple enough recipe how to reproduce the issue. It was ignored, so currently for me it just adds some score to the count when it is better to avoid an unreliable application.

This appared today - Bug 1827285 Thunderbird not displaying updates to Usenet after sitting idle

For thunderbird-102 running on Linux I have no reliable evidences that suspend to RAM causes issues with fetching of NNTP messages. Network stack at the OS level may be quite different from macOS though.