Steps to reproduce:

• Start thunderbird when a news server is down (can be simulated by adding a firewall rule that rejects packets sent to 119 remote port).
• Try to click on several messages in a news group.
• Make NNTP server available (e.g. by removing the rule added in first step).
• Try to click on the same messages again

Actual results:

• Messages are marked as read when server is down
• It is impossible to read messages when the server is recovered. Message pane is displayed blank for them. Other messages can be fetched though.

This is a regression in comparison to Thunderbird-91. There are some really old problems with intermittent network failures, but this apparent one is new.

Expected results:

• Messages remain in unread state if the NNTP server is unavailable
• Click on a message during network failure should not prevent later fetching of the message. Everything should work as soon as problems with network or the news server go away.

I have filed another Bug #1758100 for blank message pane in the case of lost network packages (DROP firewall rule). I suspect that real life scenarios may include temporary DNS resolution failures as well.

Thanks for testing beta

I am surprised by adding of the "regressionwindow-wanted" keyword. Latest thunderbird releases unlike the ESR one have JS-based implementation of NNTP. New code has another set of bugs.

My main point is that thunderbird is unreliable when intermittent network problems might happen. I am reporting problems that can be reproduced, maybe I am actually suffering from other bugs.

Wayne Mery (:wsmwk):

See Also: → 1757146

Bug 1757146 is filed for thunderbird-91, this one for the version 99. I don know real amount of changes behind the mailnews.nntp.jsmodule setting, but behavior significantly differs. The only common thing that both implementations are unreliable when intermittent network problems occur. Sometimes manifestation of problems are different, sometimes steps to a similar bug are not identical.

ping, can you reproduce comment 0?

1. do not mark failed message as read
2. remove invalid cache, so that can be fetched again

It works on 91 because onStopRequest is not called, so the progress bar is not dismissed.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/78a89772bd1b
Fix handling of nntp messages failed to fetch. r=mkmelin

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

Created attachment 9268398 [details]
Bug 1757904 - Fix handling of nntp messages failed to fetch. r=mkmelin

1. do not mark failed message as read
2. remove invalid cache, so that can be fetched again

The list looks promising.

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

It works on 91

To be clear, in 91 it may work in this particular scenario. Thunderbird-68 and 78 had some similar problem and even restart sometimes did not help to display message if network problem (wifi adapter did not waked up promptly enough) happened during fetching of a message. Unsure concerning version 91 since I enabled offline storage cache and faced even more nasty Bug 1757146 and Bug 1752806.

because onStopRequest is not called, so the progress bar is not dismissed.

You should remember that the progress bar is a real pain in recent releases (Bug 1753195)

Comment on attachment 9268398 [details]
Bug 1757904 - Fix handling of nntp messages failed to fetch. r=mkmelin

[Triage Comment]
Approved for beta

Thunderbird 99.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/f3cfcaf3c449

Thank you for the fix. This particular case seems to be worked in 100a1. Hope another Bug 1758100 related to unreliable network will be fixed some day as well.