Discovered while testing bug 192039. This has been true since at least since 1.4b, and is still the case in 1.6b-1120. If an incoming message is processed with 'Mark as Read' but not moved to another folder, the message appears in the Inbox without its New flag (green arrow). If that is the only arriving message, the Inbox also does not get a green arrow, altho the account *does* get a green arrow. This bug may affect the solution to bug 206050; I will note that there.

Oh, I forgot to note: if the filter *does* move the Marked-Read message to a different folder, the message *and* the folder are both given green arrows -- except, as noted in bug 192039, if the destination folder is being viewed, the message's green arrow is not applied.

marking a message read should remove the new flag, so I think the bug is that the folder/msg do get green arrows.

I can think of cases where marking Read but leaving New could be useful, particularly if the folder is also flagged New; however, all I really want to see is consistency. :) And that model is definitely simpler conceptually. The case where the New flag is applied to message and folder occurs when the message is filtered as Read *and* Moved to another folder. (Except for the case where the destination folder is viewed in the window, as noted in bug 192039.) Therefore, I'm converting this bug to be about the actual problem. If this is corrected, then bug 46133 will be WFM'd.

The header is ALWAYS set to new in nsParseNewMailState::PublishMsgHeader, when the message is NOT moved, even if the message is set to 'mark read'. This set to new is also done in nsParseNewMailState::MoveIncorporatedMessage: 1870 newHdr->OrFlags(MSG_FLAG_NEW, &newFlags); The message should only set to new if it's not marked as 'read', like it's done in nsMsgDBView::SetReadByIndex: 2510 if (read) 2511 { 2512 OrExtraFlag(index, MSG_FLAG_READ); 2520 AndExtraFlag(index, ~MSG_FLAG_NEW); 2521 } 2522 else 2523 { 2524 AndExtraFlag(index, ~MSG_FLAG_READ); 2525 }

this still leaves the folder with the new flag set, but that's a different problem.

fix checked in.

Verified. Thanks, David! Should I open a new bug for the folder's New flag?

New flag on destination folder: bug 230805