278609 - Empty NNTP messages after server returns error

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Martin Brommer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/0.7 StumbleUpon/1.89
Build Identifier: Mozilla Thunderbird version 1.0 (20041206)

My news server has a limited number of connections. When opening a message it
will sometimes give an error to the effect that the server is busy and the
message will open with a blank body.

After this has happened it is impossible to open the message to see the actual
message, the body will remain blank even if the server is no longer busy as if
TB caches the blank messages.

Reproducible: Always

Steps to Reproduce:
1. You need an NNTP server with a maximum number of connections.
2. Make sure the number of connections is at it's maximum
3. Open a message with TB, the server will give an error, the message will be blank
4. Open the message again when there are less connections, the message will
remain blank
Actual Results:  
The message will apear blank without any way to force TB to actually show the
content.

Expected Results:  
TB should have shown the actual body of the message

Comment 1

[Logan Shaw]

Attachment: png of error message showing nntp failure

This PNG shows that I can reproduce this on Thunderbird 1.0.2 on OS X.
See next PNG attachment.

Comment 2

[Logan Shaw]

Attachment: PNG showing that message in message pane and source of message are both empty.

This attachment shows the empty message after the NNTP error.
Note that the message in the message pane and the message in
the "message source" window are both empty.  Nothing the user
can do (except marking the message unread, then quitting and
restarting the entire app) can bring the message, even when
the NNTP server does have the article available.

Also note that, even though there was an error loaded, the message
still is marked as read (an additional incorrect behavior).

Comment 3

[David :Bienvenu]

this should be fixed on trunk builds, and thus will be in 1.1. Please re-open if
you can recreate this in a trunk build.