131769 - delete message leaves behind icon in message list

Status: VERIFIED FIXED

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

Description

[Tracy Walker [:tracy]]

seen on commercial builds:

windows 2002-03-18-05-trunk
linux 2002-03-18-06-trunk
mac os9 200-03-18-03-trunk

-open mail account (tested with imap, not sure if pop is affected because of 
workaround)

-delete one or messages
notice that the subject of the message is deleted but the icon remains in the 
list. also notice that the text body remains in preview pane.

workaround:  leave that mail folder by selecting another folder, then return to 
the original folder.  Notice the deleted message(s) are now gone complete, icons 
included.  Now delete works as expected too.

Comment 1

[Phil Pishioneri]

I can confirm this on Win2k, Mozilla build 2002031803.

Also, my previous build of 2002031505 did not exhibit this problem.

Comment 2

[lchiang]

This sounds like a regression.  Nominate nsbeta1 since this is a visible action.

Comment 3

[laurel]

I'm not seeing this with mar20 trunk build -- have tried IMAP and POP on both
win98 and linux rh6.2... there must be some other details to cause it.  I also
didn't see this with 18 or 19th build that I recall, will go try on the 18th.

Comment 4

[laurel]

OK, I did a new profile (on the 18th build) and logged in (IMAP account) and
immediately deleted messages and saw the problem.  Second launch of the profile
showed no problem deleting messages from that same inbox (immediately after login).

Comment 5

[scottputterman]

I couldn't see this on IMAP but it definitely happened on my local folders. 
This is really bad.

Comment 6

[David :Bienvenu]

I've seen this a couple times - it seems easier to recreate it if I delete the
.msf file for a folder before opening it, and then delete a message in the
folder. But that doesn't work every time either.

Comment 7

[David :Bienvenu]

taking - I might have a fix for this. I think it has to do with getting an error
in nsMsgDBFolder::OnKeyAddedOrDeleted finding the parent header for a msg that's
getting deleted. In that case, we were propagating an error back to the
notifiers, who were stopping the other notifications, one of which was getting
sent to the view. It's perfectly valid for a msg not to have a parent, so we
shouldn't be propagating the error. It also depends on the order of listeners
for the notification - if the view is before the folder, this won't be a problem. 

Comment 8

[David :Bienvenu]

Attachment: proposed fix

Comment 9

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

Comment on attachment 75249 [details] [diff] [review]
proposed fix

sr=sspitzer

Comment 10

[varada]

Comment on attachment 75249 [details] [diff] [review]
proposed fix

r=varada

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 75249 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 12

[David :Bienvenu]

Attachment: better fix - no need to get parent hdr in the first place

better fix - no need to get the parent hdr at all. We weren't using it.

Comment 13

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

Comment on attachment 75330 [details] [diff] [review]
better fix - no need to get parent hdr in the first place

sr=sspitzer

Comment 14

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

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

Comment 15

[David :Bienvenu]

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

Comment 16

[David :Bienvenu]

fix checked in so should be in today's builds (03/21/02)

Comment 17

[lohphat]

Now WFM in 2002032103 win32 build

Comment 18

[laurel]

I'm not seeing this using mar22 commercial trunk... looks OK.

Comment 19

[laurel]

OK using mar22 commercial trunk build: win98, mac OS 10.1, linux rh6.2