Select msg in thread pane, old msg still displayed in msg pane

VERIFIED FIXED in M14

Status

SeaMonkey
MailNews: Message Display
P3
blocker
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: Phil Peterson, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] Fix in hand)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Using today's build on Windows NT

1. Select a message in the thread pane, message displays in message pane
2. Select a different message in the thread pane

Expected: second message to be displayed in message pane
Actual: first message is still displayed in message pane

This doesn't always happen, but it happens frequently. Resizing the window does
not switch to the new message, so I doubt this is a repaint problem.
(Reporter)

Comment 1

18 years ago
Nominate for beta1
Keywords: beta1
(Reporter)

Comment 2

18 years ago
A little more data: this seems to happen mostly on messages I've already read in
this session. Maybe there's a cache interaction? cc mscott
Severity: normal → blocker
OS: other → Windows NT

Comment 3

18 years ago
phil,

good call.  Right before this happened to me, I got this assertion:

    // Not required to be implemented, since it is implemented by cache manager
    NS_ASSERTION(0, "nsMemCacheChannel method unexpectedly called");

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x0355ba5c, const char * 0x0355ba58, const char 
* 0x0355ba18, int 471) line 189 + 13 bytes
nsMemCacheChannel::GetContentType(nsMemCacheChannel * const 0x056e2f20, char * * 
0x0012fcd0) line 471 + 35 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x056e2f20, nsISupports * 
0x00000000) line 283 + 40 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x056e0110, 
nsIChannel * 0x056e2f20, nsISupports * 0x00000000) line 248 + 16 bytes
AsyncReadStreamAdaptor::OnStartRequest(AsyncReadStreamAdaptor * const 
0x056e2cb4, nsIChannel * 0x056e2f20, nsISupports * 0x00000000) line 131 + 37 
bytes
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x056e2c20) 
line 203
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x056e2bd0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x056e2bd0) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0159a240) line 487 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000e131c, unsigned int 49373, unsigned int 0, 
long 22651456) line 975 + 9 bytes
USER32! 77e71820()
(Assignee)

Comment 4

18 years ago
Hmm I just scanned through the checkin logs and it looks like nothing in the
cache and in the imap protocol that uses the cache have changed.

Oh I see scott's stack trace now. I'll dig into this one.
Assignee: alecf → mscott

Comment 5

18 years ago
back out rpott's change to nsCacheEntryChannel.cpp and the problem goes away.

Comment 6

18 years ago
I'm curious to see if implementing Get/SetContentType on the cache channel would
make this "Just work" trying that now.
(Assignee)

Comment 7

18 years ago
Implementing just the get should make it work. do we consider this a tree
closure regression? I think so. I'd argue that we should back it out and let
rick fix it later.
(Assignee)

Comment 8

18 years ago
Making sure rick is on the cc list since this regression came from the changes
he made to nsCacheEntryChannel last night.

According to leaf, the current plan is to open the tree, then back out Rick's
change if he hasn't had a chance to fix this yet. Then leaf will respin a set of
builds with the backout that people can use for mail.

Comment 9

18 years ago
*** Bug 29673 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
I see this on Linux, too.
OS: Windows NT → All
Hardware: PC → All
(Assignee)

Comment 11

18 years ago
I just got off the phone with Rick and we're going to change the imap
implementation to be in sync with the design changes he made to the cache last
night. More news as it happens.
(Assignee)

Comment 12

18 years ago
I have a fix in my tree for this problem.
Whiteboard: Fix in hand...waiting for the PDt+
Target Milestone: M14
(Assignee)

Comment 13

18 years ago
Created attachment 5916 [details] [diff] [review]
proposedFix
(Reporter)

Comment 14

18 years ago
[PDT+]
Whiteboard: Fix in hand...waiting for the PDt+ → [PDT+] Fix in hand
(Assignee)

Comment 15

18 years ago
Fix checked in.
(Assignee)

Comment 16

18 years ago
fixed for real.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
verified on win32 2000-03-02-09-m15 build.
Need to verify on linux and mac.
QA Contact: lchiang → fenella

Comment 18

18 years ago
Linux (2000-03-03-14 M15)
Win32 (2000-03-03-14 M15)
Mac  (2000-03-03-13 M15)
This problem has been fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.