Closed
Bug 55900
Opened 24 years ago
Closed 24 years ago
POP: Newness returns to filtered msg on next visit to folder.
Categories
(MailNews Core :: Backend, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: laurel, Assigned: Bienvenu)
References
Details
(Whiteboard: [nsbeta1+])
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
nominating rtm.
POP users who filter would be awfully confused by seeing read messages appear
new again.
Summary: POP: Newness returns to filtered msg on next visit to foler. → POP: Newness returns to filtered msg on next visit to folder.
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.
*** Bug 60227 has been marked as a duplicate of this bug. ***
Comment 4•24 years ago
|
||
marking nsbeta1+ and moving to mozilla0.8
*** Bug 64400 has been marked as a duplicate of this bug. ***
Comment 7•24 years ago
|
||
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?
Assignee | ||
Comment 8•24 years ago
|
||
OK, I've found a fix for this. I'll attach it in two parts.
Assignee: gayatrib → bienvenu
Status: ASSIGNED → NEW
Assignee | ||
Comment 9•24 years ago
|
||
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Comment 12•24 years ago
|
||
Thanks for taking care of this David.
r=gayatrib
Comment 13•24 years ago
|
||
sr=sspitzer
Assignee | ||
Comment 14•24 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 15•24 years ago
|
||
OK using apr17 commercial trunk build: linux rh6.2, win98, mac OS 9.0
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•