Closed Bug 220933 Opened 21 years ago Closed 19 years ago

Manually marking message as Junk should mark it Read as well

Categories

(MailNews Core :: Backend, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mcow, Assigned: jens.b)

Details

(Keywords: fixed1.8)

Attachments

(4 obsolete files)

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.
Product: Browser → Seamonkey
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.
Depends on: 253234
Depends on: 193625
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.
Attachment #190593 - Attachment is obsolete: true
Attachment #190593 - Flags: review?(bienvenu)
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.
Attachment #192072 - Flags: review?(bienvenu)
Attachment #192072 - Flags: review?(bienvenu)
> 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.
Attachment #192072 - Attachment is obsolete: true
Attachment #192093 - Flags: review?(bienvenu)
Attachment #192093 - Flags: review?(bienvenu) → review+
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.
No longer depends on: 193625, 253234
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 ...
Attachment #192093 - Flags: approval1.8b4? → approval1.8b4+
Carrying over r, sr and a.
Attachment #192093 - Attachment is obsolete: true
Attachment #193181 - Flags: superreview+
Attachment #193181 - Flags: review+
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: 1.20.2.1; 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: 1.96.4.1; previous revision: 1.96
done
Checking in mailnews/base/src/nsMsgDBView.cpp;
/cvsroot/mozilla/mailnews/base/src/nsMsgDBView.cpp,v  <--  nsMsgDBView.cpp
new revision: 1.222.4.1; previous revision: 1.222
done
Keywords: fixed1.8
Comment on attachment 193181 [details] [diff] [review]
branch version of above patch (checked in)

Checked in on branch.
Attachment #193181 - Attachment description: branch version of above patch → branch version of above patch (checked in)
Attachment #193181 - Attachment is obsolete: true
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.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: