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

VERIFIED FIXED in mozilla0.9.1

Status

P2
major
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: stephend, Assigned: mscott)

Tracking

({regression})

Trunk
mozilla0.9.1
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta1+])

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.
Keywords: nsbeta1, regression
QA Contact: esther → stephend

Comment 1

18 years ago
I also see this in build 2001041604 on Mac OS 9.1

Comment 2

18 years ago
That looks pretty bad. marking nsbeta1+
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1

Comment 3

18 years ago
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

18 years ago
Another case to try when verifying:  When news message is displayed (main window
or standalone message window) Toggle the View|Headers|All/Normal setting.
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.
Status: NEW → ASSIGNED
*** Bug 78040 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: nsCatFood

Comment 7

18 years ago
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

18 years ago
*** Bug 77625 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 9

18 years ago
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;
Assignee: sspitzer → mscott
Status: ASSIGNED → NEW
(Assignee)

Comment 10

18 years ago
sr=bienvenu

fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Verified fixed on:

2001050404 Windows 2000
2001050315 RedHat 7.0
2001050314 Mac OS 9.1
Status: RESOLVED → VERIFIED

Comment 12

18 years ago
*** Bug 79365 has been marked as a duplicate of this bug. ***
*** Bug 80718 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.