User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030204 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030204 Filtering mail into sub-folders works well. :) Viewing the Inbox and getting new mail (on my POP3 account) that has messages filtered into a sub-folder works correctly - viewing the sub-folder shows the messages as new. Viewing the sub-folder when the new messages are filtered into it does not show the messages as new. Reproducible: Always Steps to Reproduce: 1. view sub-folder that has mail rules to filter messages to it 2. get new messages so sub-folder gets new messages Actual Results: new messages are not shown as new Expected Results: new messages should be shown as new

Hmm, even though I've been seeing this for a while now this doesn't seem to be a dupe - heh, waddayaknow... :) - 2003013108 - win98 I haven't yet tested for moving mails to a folder at the same account, but the problem also exists for mail being moved to a folder at a different account The folder itself gets the green arrow, but the new messages in the threadpane don't. Of course, all this is probably a subproblem of the overall weirdness with notification after messages have been filtered to different accounts/filters which is bug 134153.

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

This is now affecting the unfiltered POP 'Inbox' with 1.4b (2003050714), W2K Sp3. This may be a variant. The behavior I notice is that the NEW flag does not go away in the root Inbox, even when there are no messages flagged as new. That is, either I've viewed all messages that were flagged, or (I'm not sure about this yet) the 'new' flag reappears for Inbox after I've viewed another folder and gone back to Inbox.

This symptom is not present in my testing of build 0516 on Windows 2000. Philip Nemec, Jesse Moorman, could you please verify?

Looks fixed on 2003051608 (under XP). :)

It is fixed on 20030521 on W2K

Marking WFM as this is now working and I have no idea which bug might have fixed it. Note, the problem I mentioned in comment 1 - messages filtered to a different acount - still exists, but I figure I'll file a seperate bug for that if none exists yet.

Build 2003052104; W2K Comment #3 still a problem, but maybe not a big problem: I just received 4 messages in a filtered mailbox. I looked, but did not open them. I opened another a newsgroup (maybe another folder too) and then saw the 'new' flag on the folder I'd just left. No new messages received, as far as I could tell.

Verifying WFM. re: comment 8: Jesse Moorman, could that symptom you're seeing be related to mail being filtered to some other account (or local folder)? If so, see bug 116181.

No, I don't think it is caused by messages being filtered to another folder (and there is only one account on this box), as Mozilla did not give audible signal of new mail.

Maybe another anomaly is causing this. My notebook is out for repair, and I transferred my profile (with much difficulty) back to this desktop. Now I discover that I have two matching folders with all the same subfolders and messages and filtering, and the view of the second one does not update the same as the first, that is, after sending posting comment 10, I was viewing all the folders in the first inbox and simply marking all messages as read, and then I discovered the second inbox, and the counts were different, until I opened them, and then the counts synched, and the messages were all marked as read. [I guess there might be (there should be) an RFE on Bugzilla about the difficulty of moving user profiles.] But now I'm not sure whether I was just looking at the wrong folder yesterday.

This bug just happened again for me. The open folder was flagged, but no message was flagged. I had just cleared all messages, and the message on top was only one not appearing as read, but had no flag. When I opened it, the flag on the folder disappeared. Nightly Build ID 2003052104; W2K

Jesse's right; reopening. Here's a matrix for Unread and New behavior for varying combinations of filter behaviors: Mark as Read and Move to 'dest' (folder in same account as Inbox) Tested with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030527 1) Viewing Inbox, no filtering: message Unread, New; Inbox New; Acct. New 2) Viewing Inbox, 'mark as read': message Read, not New; Inbox not New; Acct. New ** 3) Viewing Inbox, 'move to dest': message Unread, New; dest New; Acct. New 4) Viewing Inbox, 'mark as read' + 'move to dest': message Read, New; dest New; Acct. New 5) Viewing dest, no filtering: message Read, New; Inbox New; Acct. New 6) Viewing dest, 'mark as read': message Read, not New; Inbox not New; Acct. New ** 7) Viewing dest, 'move to dest': message Unread, not New; dest New; Acct. New * 8) Viewing dest, 'mark as read' + 'move to dest': message Read, not New; dest New; Acct. New * * message should be marked as New, but isn't. ** message and Inbox should be marked as New, but aren't. So, if the message is marked as Read but not moved, neither the message nor the Inbox are flagged with the New arrows, regardless of which folder is being viewed. If the message is moved to a folder, and that folder is being viewed, the message is not flagged with the New arrow (but the folder is), regardless of whether the message is marked Read or not. Note: If the destination folder is in a different account that the original, the original account is flagged, rather than the destination account; this is bug 202783.

I noticed a mistake in comment 13: case (5)'s results should be: message Unread, New; Inbox New; Acct. New ~~~~~~ Testing again per a comment in bug 219975: In the matrix in comment 13, the failure to mark a message new in cases (7) and (8) only occurs if the mail is fetched via the biff cycle; if the mail is downloaded by user command (menu, toolbar, shortcut key) the messages are correctly marked as New. These are the cases which this bug is actually about. The other issue, where filtering with Mark as Read also clears the New flag, is a different problem, and I have opened bug 227657 for it.

First, messages which are filtered and moved to an other folder are internal flaged is new. nsParseNewMailState::MoveIncorporatedMessage will call nsMsgDatabase::CopyHdrFromExistingHdr, which will create a new header and will call AddNewHdrToDB with the parameter to notify the listeners. So, the listeners will know the existence of the new header. But at this moment is the new header NOT flaged as new. This happens after calling nsMsgDatabase::CopyHdrFromExistingHdr. But no notification is send after this flag change. I think AddNewHdrToDB should be called without the notification parameter. And the notification should be called manually after the flag is changed to new. This should solve this bug. (cases 7 and 8) Why it works when you download the mails by user command? Because the junk filter is called after the download of the mails. A notification is sent if a mail changes it status (to junk or not junk). I think, if bug 219975 is solved, you will not see this bug if junk controls are activated. You will see this bug also if you disable the junk controls, and download the mails by user command. Mike: A message read implied that it's not new. You can see it in nsMsgDBView::SetReadByIndex. (http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgDBView.cpp#2504) I think you should fill a new bug if you think this is wrong, because this bug is only related to the moving part of the filter. (cases 2 and 6)

I have tested a small patch, which solves this. I have no CVS access here and no experience with creating patches, so this is only a proposal. (And I have no idea if I broke something else by calling AddNewHdrToDB in place of AddToNewList.) I added 'newHdr->GetFlags(&newFlags)' because the flags of the new header are not initialised and 'InitFlags()' is no member of nsIMsgDBHdr. Maybe 'nsCOMPtr <nsIMsgDBHdr> newHdr' could be replaced by 'nsCOMPtr <nsMsgDBHdr> newHdr' and 'newHdr->GetFlags(&newFlags)' by 'newHdr->InitFlags()'.

taking, but I'm not sure about the proposed fix- CopyHdrFromExistingHdr already calls AddNewHdrToDB, so the second call could cause some problems. Thx for the diagnosis, however, and I'll see if I can think of a way to fix this.

AddNewHdrToDB is only called if the third parameter of CopyHdrFromExistingHdr is true, that's the reason why I set it to false. The header should be set to new before AddNewHdrToDB is called. I remove the AddToNewList because it's called in the new AddNewHdrToDB call.

right you are.

I'll turn this into a diff and check it in, after testing it.

patch in cvs diff format

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

fix checked in, r/sr=mscott, thx very much, Daniel.

marking fixed.

I know this is marked as fixed, but could it have caused http://bugzilla.mozilla.org/show_bug.cgi?id=230325 ??? Now when filtering POP email to another folder with "mark as read", the mail is marked as not being read.

yes, I'm pretty sure it did. I'll look into it.

Verifying this is fixed, as is the spinoff bug 227657 and the regression bug 230325. Thanks, David and Daniel! Bug 219975 presumably has been solved as well. I've got a filter in place to move potential junk to a folder, to check that.