Closed Bug 220933 Opened 21 years ago Closed 19 years ago
Manually marking message as Junk should mark it Read as well
If a message is marked as junk from the threadpane (context menu or clicking in the Junk column) that message should be marked as read. This should be true whether the message is automatically moved to the Junk folder or not. Xref bug 211439.
There could be problems with this if people keep a storage of their junk mail for later perusal to fish out false positives (legitimate e-mail classified as spam). It would be easier to identify which junk messages have already been checked if the unread messages were not marked as being read. One reason why someone may want to keep their junk e-mail is for trying to deal to the spammer - tracing web addresses or e-mails back, and having a little chat with someone who is likely to manage the account of the spammer. I have done this on about three occasions in the past, but it requires a bit more effort than I can be bothered with unless I'm getting lots of spam from what appears to be exactly the same source.
The argument in comment 1 seems far more applicable to bug 193625, which has a patch already. I can't say that keeping certain spams unread would not be useful, but it's hardly the only tool Mozilla provides for searching and sorting mail. I wouldn't mind if the requested action were optional, but it ought to be the default and I don't see the need for extending the UI to cover the preference.
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: esther
(In reply to comment #1) > There could be problems with this if people keep a storage of their junk mail > for later perusal to fish out false positives (legitimate e-mail classified as > spam). It would be easier to identify which junk messages have already been > checked if the unread messages were not marked as being read. David, this bug is about those messages that are set as junk by the user. Are users really clicking on messages thinking "this is junk, but I want to keep it unread so I can later check whether *I* made a false positive?" I don't think so - the opposite is true: if I take the effort of marking mails as junk, I also set them as read manually. This extra step shouldn't be neccessary.
This will not work before bug 253234 gets checked in; I'm attaching this now anyway to get reviews done.
Assignee: sspitzer → jens.b
Status: NEW → ASSIGNED
Comment on attachment 190593 [details] [diff] [review] simple patch for mailCommands.js in Thunderbird & SeaMonkey Scott, could you perhaps review this really short patch?
Attachment #190593 - Flags: review?(mscott)
Comment on attachment 190593 [details] [diff] [review] simple patch for mailCommands.js in Thunderbird & SeaMonkey hooks into JunkSelectedMessages (TB & SeaMonkey) and marks as read when the corresponding setting is enabled
Attachment #190593 - Flags: review?(mscott) → review?(bienvenu)
I don't like the patch for two reasons. First, it relies on the same 'mark as read' flag that's used for the case where I *don't* want junk marked read: when it's automatically flagged as junk. Either manually marking as read should *always* mark the junk read, or else be controlled by a separate preference. Second, it doesn't work if you mark a message junk by clicking in the junk column in the thread pane, which is by far the most common technique for me.
(In reply to comment #7) > I don't like the patch for two reasons. First, it relies on the same 'mark as > read' flag that's used for the case where I *don't* want junk marked read: when > it's automatically flagged as junk. Either manually marking as read should > *always* mark the junk read, or else be controlled by a separate preference. Agreed. On manual marking, we should always set as read. > Second, it doesn't work if you mark a message junk by clicking in the junk > column in the thread pane, which is by far the most common technique for me. In fact, that does work on current trunk builds, but it also depends on the preference. To match the marking via toolbar/menu, it should always mark as read, too.
David, I discovered that there's a mismatch between clicking on the junk column (marks as read according to pref) and toolbar/context menu (doesn't mark as read). This patch unifies the behaviour to *always* mark as read, regardless of the pref, to better match user expectations.
> Always mark messages as read when flagged as junk, pref-independent Well, no thanks -- I rather like the idea of the 'read' flag meaning 'read' :\ The two relevant prefs are markAsReadOnSpam and moveOnSpam. Let me outline the matrix of scenarios: - When markAsReadOnSpam is set, manual marking as Junk should definitely mark as read as well. - When markAsReadOnSpam is not set: - If moveOnSpam is not set, the message stays right in front of the user when marking as Junk, so marking it read as well may be reasonable, to get the message out of the user's way. - If moveOnSpam is set, the message gets out of the way by moving to the Junk folder; losing the read state of the message(s) is unnecessary. The Junk folder will already contain unread Junk, so having more appear is not a problem. In short, marking as read when manually marking as junk should happen if (markAsReadOnSpam || !moveOnSpam).
As agreed on IRC. Fixes previous patch by only marking as read when junking, not when un-junking.
Comment on attachment 192093 [details] [diff] [review] Always mark messages as read when flagged as junk, pref-independent (checked in on trunk) dmose, could you sr this? In the meantime, bienvenu and I agreed to not make this pref-dependent, as the markAsReadOnSpam pref is about the automatic classification.
Attachment #192093 - Flags: superreview?(dmose)
Removing the dependencies, as we won't use the markAsReadOnSpam pref anyway.
Comment on attachment 192093 [details] [diff] [review] Always mark messages as read when flagged as junk, pref-independent (checked in on trunk) sr=dmose
Attachment #192093 - Flags: superreview?(dmose) → superreview+
Comment on attachment 192093 [details] [diff] [review] Always mark messages as read when flagged as junk, pref-independent (checked in on trunk) It would be great if this could make it into the beta. It's a very-low-risk checkin which lets Thunderbird (and SeaMonkey) just "do the right thing" (i.e. what the user expects) without introducing further complexity. I tested all ways to mark messages as junk, and this doesn't seem to have any side effects.
Attachment #192093 - Flags: approval1.8b4?
Attachment #192093 - Attachment description: Always mark messages as read when flagged as junk, pref-independent → Always mark messages as read when flagged as junk, pref-independent (checked in on trunk)
Seems like UI changes like this should get at least a look from our UE person before we drop them on our soon to be shipping branch.
(In reply to comment #16) > Seems like UI changes like this should get at least a look from our UE person > before we drop them on our soon to be shipping branch. As I follow this discussion (bits occured on IRC so I had to make some assumpions) and the patch, this means ..: - when junk is automatically marked by the filters it is not marked as read unless an unexposed pref is changed - when junk is manually marked by a user (through clicks in the junk column, right clicks on the message, or by clicking the "Junk" button) then it also gets marked as read, whether or not it's automatically moved to the Junk folder. Sounds reasonable to me, and very much like the right thing to be doing.
(In reply to comment #17) > As I follow this discussion (bits occured on IRC so I had to make some > assumpions) and the patch, this means ..: (...) Correct, that is the behaviour. Thanks for taking a look, hope it wasn't too difficult to get an overview.
no problem; I'm learning! I even read the patch and caught a drift of what was going on ...
Carrying over r, sr and a.
Checked in to MOZILLA_1_8_BRANCH: Checking in mail/base/content/mailCommands.js; /cvsroot/mozilla/mail/base/content/mailCommands.js,v <-- mailCommands.js new revision: 18.104.22.168; previous revision: 1.20 done Checking in mailnews/base/resources/content/mailCommands.js; /cvsroot/mozilla/mailnews/base/resources/content/mailCommands.js,v <-- mailCommands.js new revision: 22.214.171.124; previous revision: 1.96 done Checking in mailnews/base/src/nsMsgDBView.cpp; /cvsroot/mozilla/mailnews/base/src/nsMsgDBView.cpp,v <-- nsMsgDBView.cpp new revision: 126.96.36.199; previous revision: 1.222 done
Comment on attachment 193181 [details] [diff] [review] branch version of above patch (checked in) Checked in on branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I guess it's too bad checking the bug in :(. Don't make mozilla like a Microsoft product, in which the main problem is absence of a big button: DO NOT TRY TO HELP ME! If I need a message to be read I'll just mark it as read. Please keep mozilla as simple as possible, otherwise It'll be like a gruel.
Arkady, no name-calling, please :) I did argue on irc for keeping imo better semantic simplicity, but it was agreed that removing the "Mark as Junk" function and replacing it with a "Mark as Junk and Read" function mislabeled as "Mark as Junk" isn't too atrocious in that regard, and doesn't break real use cases, while making the common case of marking a message as junk and read a bunch less tedious. If you have a real use case that this change makes more circumlocutious, feel free to weigh it against the others and maybe raise it (perhaps in a separate rfe/bug).
There is another vote already in https://bugzilla.mozilla.org/show_bug.cgi?id=306026
I finally got a chance to check this, and it is indeed fixed (1.6a1-0830). Thank you, Jens! (I can suggest a few other bugs to work on if you've got the urge... :) An additional benefit to this change is, if the only message received is an undetected piece of spam, marking it as junk now clears the account's New flag and the notification icon in the tray.
Status: RESOLVED → VERIFIED
sigh. i performed a search to submit the "opposite" of this bug when i found this, and that the behavior is something somebody else considers fixed. first, in the case where there are duelling bugs like this, it seems it should definitely be a user-option. second, the comments seem to indicate that those who fixed this bug believe that in every case, the user who marks a message as junk has actually read the message. in my case, i often don't read the message but merely mark it as junk from looking at the subject and sender ... meaning i have not read the message, but it is being marked as such. i agree very much with arkady's comment #23 https://bugzilla.mozilla.org/show_bug.cgi?id=220933#c23 ; don't automatically help me organize thing the way you think they should be organized. in a case like this, where opinion is so divided about how to proceed, a user-pref is the only real solution ... but definitely don't take away behavior that i consider to be the proper working solution. (i guess i'm left to vote for bug https://bugzilla.mozilla.org/show_bug.cgi?id=306026 in order to back out this broken behavior.)
Neato. Now when you mark a message as Junk it disappears into your Junk folder and you'll never find it if it had an invalid date (and we all know spam never has invalid dates) because it's marked as read. Nice. The Mozilla usability-decreasing team strikes again.
(In reply to comment #25) > There is another vote already in > https://bugzilla.mozilla.org/show_bug.cgi?id=306026 > I have a problems with this change besides the fact that you are telling me how I should want to do my work. When I receive over 250 junk mails a day, I select view non junk, read through the sender and subject, setting the non-junk emails to junk for those I want to be junk. I then select view to all and and I now have a bunch of messages set to junk with part of them marked read and part of them not marked read. Now I have to clean up the mess that is made of my in box as to what is read and what is not. I want to then mark all the junk messages as read and delete them from my in box, in order to insure that I do not have unread messages in my trash. The current behavior is inconsistent depending on who or what marks the message as junk. Inconsistent behavior is always a red flag in programming. Make a decision to do it one way or another, but do not make it half and half.
Is there somewhere in the program that manually marking a message as Junk does something different? If there is, file a bug. If not, there is no inconsistent behavior.
You need to log in before you can comment on or make changes to this bug.