From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.4.0-test10 i686) BuildID: Build IDs 2000101015 (M18) and 2000120708 The message pane is not cleared when the message is deleted from the messageWindow.xul toolbar. Reproducible: Always Steps to Reproduce: 1. Open E-Mail 2. Double-click on a message so it's opened in a separate window 3. Selete delete on the toolbar Actual Results: The message is deleted but its contents are still displayed in the message pane. Expected Results: Expect the message pane to be cleared since the message has been deleted. Don't know if it matters but I'm using an IMAP server and had several messages displayed in the folder. In M18, msgMail3PaneWindow.js receives the DeleteOrMoveMsgCompleted event; the specified nightly build no longer receives this event. Since the delete was performed from a different window, gNextMessageAfterDelete will not be set (=null) and no message selection will occur in HandleDeleteOrMoveMsgComplete.

taking from putterman.

OS -> All Platform -> All

Isn't this a dupe of bug #33209 ? But there it's marked as WORKSFORME. I have seen this bug today as well (using POP3; Linux build 2001012921), but I can't reproduce it now.

I think the other bug was talking about regular messages in the window pane, not the stand alone one. We also have a bug regarding the title of the last message in the pane not leaving when it's deleted.

I think this is another way to reproduce the same defect: 1) Make sure there is only message in your INBOX. 2) Select it. 3) Hit "delete". The message is deleted from the thread pane, but the body is still displayed in the message pane.

I bet this is easy, once we figure out what wrong with the OnMailWindowUnload() function in mailWindow.js is doing ;-)

reassigning to self. I have a fix in hand.

The if else was messed up here. The code when gNextMessageViewIndexAfterDelete = -1 was never getting executed. Need review.

looks good to me - r=bienvenu. Maybe Seth can look at it too - it's a little confusing because of that braces style :-)

fix checked in.

reopening. misread the bug report. I was trying to fix something else.

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

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

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

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

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

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

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

My understanding is that this bug is broader. Not only for deleted messages the message pane in not cleared. For all actions which unselect a message, it stays the same. This happens, e.g., if you edit a draft, compare bug 108230. Summary should reflect that. pi

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

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

bug 112662 probably is a dupe of this bug. But bug 112662 has more recent activity.

Using todays build of 11th August from 5:30 I do not see this behaviour anymore. Would be great to see that 1.1 will not ship with that BUG. Don't know what caused it to get it resolved, as far as I can see the patch is not yet checked in. //Carsten

naving, do you know of anything that would have caused this bug to no longer be reproducible on the trunk (something since 1.1 branched on 2002-08-05 ?

I am finding the same behavior on a 2 days old trunk build and on 1.0.1 branch build. The message-pane is not cleared. looks like nothing has changed. will look into it more...

@Navin: You're right I was focusing on comment #4 and #5. I also see this behaviour when I double clicked on a message but not anymore when just deleting the last message in the inbox. This works now, the lower message pane is cleared to solid white. Again, this does not work yet when double clicking on a message. //Carsten P.S. I last build before this build on 12th July, at this date the behaviour of #4 and #5 were still present, also this behaviour is present in 1.1b.

this bug is essentially a dupe of bug 172392 (which already has a patch under review) *** This bug has been marked as a duplicate of 172392 ***

verified dup. I'll check this case when bug 172392 is fixed.

I don't believe this bug is a dupe, because the symptom described in the original report is no longer presenting (1.4RC1-Win2K, and 1.3 Final for that matter), whereas the symptom in the alleged dupe is still in place. Anyone care to confirm that and WFM this?

=>WFM

Verified.