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.

Nominate for beta1

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

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()

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.

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

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

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.

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.

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

I see this on Linux, too.

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.

I have a fix in my tree for this problem.

[PDT+]

Fix checked in.

fixed for real.

verified on win32 2000-03-02-09-m15 build. Need to verify on linux and mac.

Linux (2000-03-03-14 M15) Win32 (2000-03-03-14 M15) Mac (2000-03-03-13 M15) This problem has been fixed.