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 <3B00069A.email@example.com> (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.
Summary: Valid newsgroup displayed as Expired under certain conditions → Valid newsgroup articles displayed as Expired under certain conditions
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Networking - News
Ever confirmed: true
QA Contact: esther → stephend
*** Bug 96702 has been marked as a duplicate of this bug. ***
nominating for nsbranch
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.
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.
Severity: normal → critical
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.
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.
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.
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.
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.
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.
What's the problem of caching the socket's running URL if the next article is in the same group? Did I miss something?
not a stopper for emojo.
Keywords: nsbranch → nsbranch-
sorry for the delay, I'll go review the patch.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
With the patch from bug 59449 and this patch, this has fixed the problem for me!
even though it doesn't seem like it, this is a dup of #59449 *** This bug has been marked as a duplicate of 59449 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Yes, dup. Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.