76558 - Message source showing after selecting a posting and going back to it in a thread.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

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

Build ID: 2001041804 on all OSs.

Summary: Message source showing after selecting a posting and going back to it
in a thread.

Steps to Reproduce:

1.  Go to a new thread in news.
2.  Click on the top level posting.
3.  Click the twisty.
4.  Click on the next news posting.
5.  Go back to the top level posting (beginning of thread).

Expected Results:

News posting displays as usual.

Actual Results:

Entire message source is displayed in plain text.

This is probably a cache bug.  cc:ing mscott.

Comment 1

[TommyBee (No E-mail)]

I also see this in build 2001041604 on Mac OS 9.1

Comment 2

[scottputterman]

That looks pretty bad. marking nsbeta1+

Comment 3

[laurel]

Anytime you display a posting a second time, this is happening. Here's a couple
more cases:
1.  Select a posting in the thread pane while the message pane is shown. Message
contents load in the message pane. Now press Enter or double-click to open that
same message in a standalone message window --> opens to the incorrect display.
2.  Do the reverse of the above case -- select a posting in the main mail window
when the message pane is closed. Open to standalone message window, which
displays correctly. Now go back to main mail window and open the message pane
--> incorrectly displayed.

Comment 4

[laurel]

Another case to try when verifying:  When news message is displayed (main window
or standalone message window) Toggle the View|Headers|All/Normal setting.

Comment 5

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

it sounds like it happens when we load a message the second time from the memory
cache.

I'll check if there are prefs to disable the memory cache (perhaps set its size
to 0) and see if the problem still happens.

Comment 6

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

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

Comment 7

[R.K.Aa.]

i'm sorting news-messages by date, and this is a very easily reproduced bug.
Cache sounds right. Clicking msg "backwars" the second time will always render
it garbled. The third time onwards always works OK. Try this pattern:

messages #:
1
2
3
4
5
6

click 6: OK
click 5: OK
click 6: garbled
click 4: OK
click 5: garbled
click 3: OK
click 4: garbled
click 2: OK
click 3: garbled
click 1: OK
click 2: garbled

Comment 8

[scottputterman]

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

Comment 9

[Scott MacGregor]

I have a fix for this. Re-assigning to myself. 

There was a race condition with the new cache where sometimes we weren't
clearing the content type from the previous load on the protocol....

Index: nsNNTPProtocol.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/news/src/nsNNTPProtocol.cpp,v
retrieving revision 1.258
diff -u -r1.258 nsNNTPProtocol.cpp
--- nsNNTPProtocol.cpp  2001/04/27 21:30:00     1.258
+++ nsNNTPProtocol.cpp  2001/05/02 00:34:47
@@ -742,6 +742,7 @@
     cacheListener->Init(m_channelListener, NS_STATIC_CAST(nsIChannel *, this),
mailnewsUr
l);

     nsCOMPtr<nsIRequest> request;
+    m_ContentType = ""; // reset the content type for the upcoming read....
     rv = cacheTransport->AsyncRead(cacheListener, m_channelContext, 0,
PRUint32(-1), 0, g
etter_AddRefs(request));
     NS_RELEASE(cacheListener);

@@ -749,7 +750,6 @@
     if (NS_SUCCEEDED(rv)) // ONLY if we succeeded in actually starting the read
should we
 return
     {
       // we're not calling nsMsgProtocol::AsyncRead(), which calls
nsNNTPProtocol::LoadUr
l, so we need to take care of some stuff it does.
-      m_ContentType = "";
       m_channelListener = nsnull;
       return rv;

Comment 10

[Scott MacGregor]

sr=bienvenu

fix checked in.

Comment 11

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

Verified fixed on:

2001050404 Windows 2000
2001050315 RedHat 7.0
2001050314 Mac OS 9.1

Comment 12

[laurel]

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

Comment 13

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

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