Deleting one or more unread messages via a user action (Del key, toolbar button, menu) from the Inbox leaves the messages unread. Deleting messages with a filter marks the messages read. Since Move to Trash is available for those people who actually want to keep the messages in the Trash marked as Unread, delete should always mark the messages as read. Ideally, undelete would restore the unread mark, if necessary.

xref bug 220933, bug 157115.

Works now, but was it intentionally? See Bug 274022.

yes, it was absolutely intentional.

This bug has NOT been fixed. Bug 274022 is only about IMAP mail, where the Unread status is actually maintained on the server, and only with the "Mark as deleted" deletion model. This bug was originally opened for the POP case, which behaves as always. IMAP deletion that moves to Trash also behaves as always. My expectations for the "mark as deleted" case would be that it's better to mark the mail as read, as well; however, there isn't an option to mark as deleted *and* leave unread in a single operation (as opposed to using an explicit Move To Trash which would leave messages marked as read, even if Delete does not). I guess I don't understand why someone would want to Delete a message -- which to my mind has an implicit meaning of "I'm done with this message" -- and yet still have it listed Unread.

To comment 4 , there could be lots of reasons why an user would like messages marked as deleted to _not_ be marked as "read': 1) Users change their minds. A group of unread messages that have been marked as deleted may be again marked as undeleted when the user feels that he/she does not want to delete them after all. In this situation, they must not be marked as read because the user has not yet read them. What is worse is that now the users lose track of which mails they have actually read because now some de facto unread mails have been marked as "read". Users do rely on the email client to tell them if they have/have not read an email. 2) SPAM/viral mails/unwanted emails. Why would an user _want_ to select and then delete a group of spam/viral mails and then be made to think that he/she actually "read" _all_ of these unwanted emails !? I would strongly suggest reopening bug 274022 . Also, note that bug 274022 was reproduced in a user-selected setting where mails were being marked deleted _without_ moving them to trash. As for the option "mark as deleted and leave unread", I am in favor of that too. The current situation is however very problematic.

(In reply to comment #2) > Works now, but was it intentionally? I have to apologize, it is not WFM, only to some extent. I have tested it with Mozilla 1.8a6/1.7.5 build 2004121205/2004121311 on WinNT4/WinXP with POP3 accounts. I have set the pref mailnews.mark_message_read.delay to true and mailnews.mark_message_read.delay.interval is the default 5 s. Results: A unread message will be unread in Trash if I delete the message almost immediately after selecting. If I wait a little bit more (but definite less than the delay interval, see above) the message will be moved as read to Trash. I deleted with Del key. Note: Bug 274022 is transformed to a RFE "add option to to mark mail read when deleting mail, off by default".

fwiw, my main focus when I filed this bug was selecting a bunch of messages and deleting them at once; with the multi-select, at most one of them would be marked read as part of the selection process. At the time I filed the bug, the delay was unimplemented. I was also deleting some single messages with the context menu when I did not want to load them into the message pane.

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

Just wanted to throw in that marking an unread message as read when moving it to the trash should abide by the rules that the user sets for handling return receipt requests ... isn't there a response to a return receipt that states that the message was deleted without being read (I think I remember that as a standard response)? If that's the case, then marking an unread message as read when moving it to trash should still trigger that response, and NOT send a return receipt of the message being read, at least in my opinion.

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

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

wanted‑thunderbird3-; patches welcome though.

(In reply to comment #12) > wanted‑thunderbird3-; patches welcome though. at your command ;)

Simple as that ? (I didn't yet digged enough in the code but there might be a need to combine MarkCurrentMessageAsRead() and MsgMarkMsgAsRead(markRead) functions ?) BTW based on the code comments this is bug not enh

Comment on attachment 344535 [details] [diff] [review] Proposed fix v1 > if (gMarkViewedMessageAsReadTimer) > MarkCurrentMessageAsRead(); >+ MsgMarkMsgAsRead(null); Wouldn't just MarkSelectedMessagesRead(true); do instead of these tree lines? (And the indention is off there...)

(In reply to comment #15) > Wouldn't just MarkSelectedMessagesRead(true); do instead of these tree lines? it does, thanks :)

Updated to comments.

Comment on attachment 344758 [details] [diff] [review] Proposed fix v2 Looks good, thx! I though about just using ClearPendingReadTimer() for the shift delete case, but then it still doesn't mark as read for offline imap (+mark as deleted model) r=mkmelin, will check this in for you in a sec

changeset: 722:87a45e48e892 http://hg.mozilla.org/comm-central/rev/87a45e48e892 ->FIXED

-> VERIFIED Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081027 Lightning/1.0pre Shredder/3.0b1pre Finally small but sometimes annoying bug is fixed :)