95320 - Valid newsgroup articles displayed as Expired under certain conditions

Status: VERIFIED DUPLICATE of bug 59449

(MailNews Core :: Networking: NNTP, defect)

Description

[kumar.bharat]

When using Spacebar to skip go between newsgroup articles, if the spacebar is
pressed fast twice, some articles might be skipped, and future articles
displayed. However, if you click on a skipped article immediately afterwards, it
is shown as Expired. Further, if you go to some other article, and then come
back to the "problem" article, it will be displayed correctly.

To reproduce (note that this problem MAY be reproducable by other means, but I
didn't attempt to find all the cases where this problem occurred):
1. Go to a newsgroup and view as threads (I chose n.p.m.style)
2. Expand a thread by clicking on the triangle/arrow icon (don't select a message).
3. Make sure that the thread has at least 3 or more articles. If not, try
another thread.
4. Select the first article in the thread, and wait until it loads fully. The
article will be displayed properly.
5. Press spacebar until you reach the end of the article in the content frame.
If the article is already fully displayed, skip this step.
6. Press spacebar twice in quick succession, so that the second article in the
thread is skipped, but the third article in that thread is visited.7. Now visit
the second article (that was skipped). You'll get the error:

Error!
newsgroup server responded:Not in a newsgroup
Perhaps the article has expired
<[e-mail]> (688)
Click here to remove all expired articles

8. Now visit some other article (doesn't matter which one).
9. If you again visit the article that gave the Expired error before, this time
that article will be displayed properly.

This is reproducable always.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 96702 has been marked as a duplicate of this bug. ***

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

nominating for nsbranch

Comment 3

[Daniel Bratell]

As I said in the duplicate bug, this is a bug that has caused concern from 
posters on n.p.m.m-n who didn't understand that it was a Mozilla bug and many 
people won't go back to the post never getting the content causing some kind of 
dataloss.

Comment 4

[Håkan Waara]

I use news a lot, and this is killing me. I have to reload messages very often
due to this. Sometimes I won't even know whether the article had expired or if
the loading was just incomplete.

Comment 5

[Håkan Waara]

Better reproducible steps:

1. Find a newsgroup with a few unread threads
2. Expand one thread with a few messages
3. Click a msg, and before it has finished loading, click another one.
4. Wait until the msg loads properly.
5. Click the msg you "skipped" - it will say it is expired.

Comment 6

[Phil Anderton]

What seems to be happening at the protocol level is that MailNews has several
(2-4) TCP connections to the news server. (Why?)
The error occurs when MailNews initiates a new TCP connection, and sends an NNTP
ARTICLE request without first sending a GROUP request. The news server,
understandably, replies with "412 Not in a newsgroup".
Obviously, MailNews should be sending a GROUP request, but equally it should not
be reporting "Perhaps the article has expired", etc.

Comment 7

[Phil Anderton]

What's happening is that when a MailNews thread closes a socket, m_currentGroup
still contains the newsgroup name. When the same thread makes a new connection,
nsNNTPProtocol::SendFirstNNTPCommand doesn`t send a GROUP request: "if the
current group is the desired group, we can just issue the ARTICLE command".
Attaching a patch to at least fix the symptom by blanking out m_currentGroup
whenever a socket is closed.

Comment 8

[Phil Anderton]

Attachment: Proposed patch

Comment 9

[Daniel Bratell]

Great find! I'm not the one to review this but I can confirm that it kind 
of works. I no longer get the "expired" message but Mozilla is displaying the 
raw text of the mail instead of the mail formatted by the mime component. Since 
the viewer expects HTML, the output is quite unreadable. I've seen this before 
at times but now it seems to be reproducible. Maybe there is something else that 
also should be cleared.

As for the code I would guess that the code to clean things up should be in 
CleanupAfterRunningUrl() (and the comment after the call to 
CleanupAfterRunningUrl should be removed). There is also a tab in the line below 
your addition that should be removed when we're there changing the code. Also, I 
think m_currentGroup.Truncate() is the most efficient way to clear a string, but 
I guess it's best to follow the style in the code.

I hope you can find why the post is displayed without going through mime (or 
without being converted to HTML at least) also. That is almost the last major 
display problem I know of.

Comment 10

[Phil Anderton]

I think you mean that this fix seems to provoke bug 59449 - I noticed that too, 
but not consistently. I don't think CleanupAfterRunningUrl is the right place 
for this fix - it gets called from a number of places, which would lead to a 
GROUP request being sent more often than needed.

Comment 11

[Daniel Bratell]

I believe you. I'm looking forward to hearing sspitzer's comments on your fix.
Anyway, it's fixed in _my_ tree, :-) Thanks for the pointer to bug 59449, I've
been loking for that.

Comment 12

[Håkan Waara]

What's the problem of caching the socket's running URL if the next article is in
the same group? Did I miss something?

Comment 13

[Scott MacGregor]

not a stopper for emojo. 

Comment 14

[(not reading, please use [e-mail] instead)]

sorry for the delay, I'll go review the patch.

Comment 15

[Håkan Waara]

With the patch from bug 59449 and this patch, this has fixed the problem for me!

Comment 16

[(not reading, please use [e-mail] instead)]

even though it doesn't seem like it, this is a dup of #59449


*** This bug has been marked as a duplicate of 59449 ***

Comment 17

[[e-mail] (gone - use [e-mail] instead)]

Yes, dup.

Verified.