55900 - POP: Newness returns to filtered msg on next visit to folder.

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[laurel]

Using oct9 mn6 branch commercial build
Tried with linux rh6.0 and mac OS 9.0, assume same on NT 4.0
Found while verifyin bug 20750

After reading a filtered POP message in its destination folder (filter action
was to move it) the message status changes to Read, loses its bold text, green
Newness arrow and green unread diamond. Switch to another folder then back and
the message is now New again -- Status column shows New again and green arrow
displays.

1.  Set up a simple filter for a POP account which has an action to Move To
Folder (on same account).
2.  Send your POP account a message which will match the filter criteria, Get
that message.
3.  Filter fires and message is moved to the destination folder. Destination
folder gets New green arrow.
4.  Select the destination folder and see the message also has New green arrow
and the Status column says New.
5.  Select the message (message pane is open).  Message is displayed. New Green
arrow goes away, message status goes to Read.
6.  Select another folder then go back to the filter destination folder. Notice
the message which was read is now New again, complete with green arrow and
status column "New".
7.  Note:   the false newness will not retain through exit.

Result:  Message is marked read, then goes back to New upon revisiting the folder.

Expected:  Message is read, stays read and should not appear New again.

Comment 1

[laurel]

nominating rtm.
POP users who filter would be awfully confused by seeing read messages appear
new again.

Comment 2

[esther]

Sorry for no explanation for rtm-. Per triage, no data loss, some of the
visualsthat show the message has been read are still working (non-bold and
unread button not green) in thread pane.  Folder pane folder not bold and status
recovers after exit.

Comment 3

[laurel]

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

Comment 4

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 5

[laurel]

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

Comment 6

[scottputterman]

moving to mozilla0.9

Comment 7

[Håkan Waara]

I've been seeing that sometimes the "newness" of a message doesn't clear when
it's read. This extremely irritating... is that the same bug or should I open a
new one?

Comment 8

[David :Bienvenu]

OK, I've found a fix for this. I'll attach it in two parts.

Comment 9

[David :Bienvenu]

Attachment: proposed fix, part 1

Comment 10

[David :Bienvenu]

Attachment: proposed fix part 2

Comment 11

[David :Bienvenu]

there were several things going wrong here - the pop mail filter code was never
telling the db that the newly filtered msg was new. This led to a chain of
badness where the nsMsgDBFolder thought it had new, but the db didn't know it
had new, and bad things happened. Furthermore, the code that retrieved msg
status was never clearing the new flag based on the db's new set (it would only
set it, not clear it). This caused some more confusion. And the code that marked
headers read was not clearing the NEW flag from the header - it just removed the
msg key from the new set.

So, with these changes, it works much better for me. However, it's so much more
complicated than it should be, with all these different pieces of code keeping
track of new state (the nsMsgDBFolder, the db, and the individual msg headers).
Ideally, only the db would keep track of the new state, and would be trusted
over the other two. I've made the db override the hdr flags in terms of newness,
but it's harder to get rid of the new state on the folder because of IMAP,
basically - when messages get filtered to an imap folder, we don't know anything
about the new msg headers, so we can't add their keys to the db's new set until
we select the folder on the server, so we're kinda stuck for now.

Comment 12

[gayatrib]

Thanks for taking care of this David.
r=gayatrib

Comment 13

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

sr=sspitzer

Comment 14

[David :Bienvenu]

fix checked in.

Comment 15

[laurel]

OK using apr17 commercial trunk build: linux rh6.2, win98, mac OS 9.0