Closed Bug 306026 Opened 18 years ago Closed 18 years ago

Manual marking a message as junk marks the message as read as well.

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: asherman, Assigned: jens.b)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 2 obsolete files)

introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]
6.76 KB, patch
jens.b
: review+
jens.b
: superreview+
mscott
: approval1.8rc1-
mscott
: approval-branch-1.8.1+
mscott
: approval1.8.0.2-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050821 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050821 SeaMonkey/1.0a

If I manually mark a new message as junk by clicking onto the corresponding
column the message is moved to junk folder (as specified in the junk
preferences), with mark as read being made as well for the message (though,
"Mark messages determined to be junk as read" is switched off in the junk mail
controls preferences).  

Reproducible: Always

Steps to Reproduce:
1. Specify n the junk mail controls preferences "When I manually mark messages
as junk" as "Move them to the junk control"
2. Obtain a new message
3. Do not select the message, but specify it as junk by clicking to the
corresponding column.
4. Open the junk mail folder in see that the messsage marked as read. 
4.

Actual Results:  
Incorrectly mark a message as read If the message manually marked as junk.

Expected Results:  
Don't mark messages as read If messages manually marked as junk.
I noticed this too, in the 8-23 Windows nightly. I expected the messages in my
junk folder to correctly indicate whether I've read them. 
Please vote for this in https://bugzilla.mozilla.org/show_bug.cgi?id=220933
Actually, please don't vote for this in bug 220933. That's a closed bug, and not
the right place. This is a new, open bug, and the right place for comments for
this change to the function.
Arkady and John, please let us know exactly which use case is made cumbersome by
the changed behaviour, so the Thunderbird/Mailnews module owners can weigh it
against regular usage and decide what should happen. By "use case" I don't mean
steps to reproduce, but an answer to the question "Why do you want
SeaMonkey/Thunderbird to remind you of the junk mails that you have already
dealt with?", or alternatively "In which situation do you need to find again
that message which you marked as junk but did not read?".
(In reply to comment #5)
> ... please let us know exactly which use case is made cumbersome by
> the changed behaviour
>
> "Why do you want SeaMonkey/Thunderbird to remind you of junk mails that you
> have already dealt with?"
>
> "In which situation do you need to find again that message which you marked
> as junk but did not read?"

my two use cases:

[1] first, i leave messages in trash for a long while, including junk and
non-junk together, partially in an effort to keep a sort of running ratio of
things that are legitimate email versus spam.  the higher this percentage, the
less spam i am getting from the outside world.  with the old behavior, this used
to be easy, because all junk -- whether auto-moved or manually marked without
looking at it but simply reading the header and marking it as such in the header
pane without the message being visible in the message pane -- would remain
marked as unread.  now this calculation is cumbersome and annoying because i
actually have to do one of two things:  {a} set the control in junk mail
controls to move a message to trash i mark as "junk", and then after marking a
message as junk <i> click on the trash <ii> scroll around to find the message i
just marked as junk <iii> click on the "read/unread" marker.  or {b} set the
control in junk mail controls *not* to move a message to trash i mark as "junk"
and then, to get the message to the trash <i> actually navigate to the message i
wish to mark as junk <ii> mark it as junk by clicking in the junk column or
hitting "j" <iii> now that thunderbird has also auto-marked it as read (because
i have my "don't mark as read for 4 seconds" setting established), either hit
"m" or click the "read/unread" column <iv> either drag the item to the trash,
click the "just say no" delete icon, or hit "del" to get the message to the
trash.  either way, this is multiple steps ({a} is quite a bit more cumbersome
because it involves switching to the trash and searching for items, but {b} has
the disadvantage that i now actually have to see the junk message in my message
pane for a few seconds.  even though i have to see this now, i have been
performing the 4 steps in {b} to accomplish what i used to be able to do in one
click in the 'junk' column.

[2] a side-effect of [1] is the use-case where i wish to go into the trash and
find a message i deleted by accident.  it used to be the case that i could
visually eyeball the messages in the message pane and distinguish by bold versus
non-bold which ones i wanted to scan to look at.  i suppose i could look at the
junk column only, but this is slightly more difficult, because it requires
eye-scanning to the right to see that column, and then back to the left to see
the subject line or sender of the message in question that i am looking for.

use case [1] is one i perform several times a day, every time i manually
download email and every time i check email after i've been out of the
thunderbird app for a while and email has auto-downloaded, because i eyeball the
value in the folder column regularly just as a sort of gauge of what's going on.
 use case [2] only comes up if i don't perform the cumbersome steps of [1], and
would probably only occur once every few days (and could probably be worked
around with the creation of a proper header-filter in the menu above the headers
pane, i suppose; for that matter, i could move stuff to the "junk" folder, but i
prefer to have fewer folders which is why i've never used the special "junk"
folder from the junk mail controls in the first place.)

(and aside from the specific use-case, to me, in marking a message as "junk"
without reading it and having it auto-move to the trash, it makes complete sense
to me that the message was really "unread", because i never actually read it.)
I see this on OS/2, as well (currently using 2005-08-30). For me, the use case
is that I don't turn on the total column in my folder pane, so usually, the
unread message count (shown by default) gives me a tally of all of the junk
messages in the folder. As it stands now, this is only an unread tally, so I
really have no idea how much junk I have in there, without manually opening the
folder and resetting the read flag.

Lewis

PS - I'll leave changing the OS field on this bug to someone else.
Here's my usage issue. The program marks messages as junk, sometimes correctly,
sometimes not. If I have looked at a message and decided that it's junk and then
later look at my junk folder and see it marked as read, I have no doubt that I
marked it according to my wishes. If they are ALL marked as read, I don't know
which ones I personally checked out and which ones were automatically assigned
to the junk folder. I do check the junk folder because sometimes good messages
are improperly put there.

(In reply to comment #8)
> Here's my usage issue. The program marks messages as junk, sometimes correctly,
> sometimes not. If I have looked at a message and decided that it's junk and then
> later look at my junk folder and see it marked as read, I have no doubt that I
> marked it according to my wishes. If they are ALL marked as read, I don't know
> which ones I personally checked out and which ones were automatically assigned
> to the junk folder. I do check the junk folder because sometimes good messages
> are improperly put there.

the fact that there are disparate and conflicting usage issues has me thinking
the best solution would be a Junk Mail Controls user-pref something like 'when
manually marking messages as junk, also mark them as "Read"'.  i could leave
this off for my use case, and the author of comment #8 check this pref for his
use case.

Confirming (= valid request, no duplicate). Note that this doesn't imply a decision.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
(In reply to comment #8)
> Here's my usage issue. The program marks messages as junk, sometimes correctly,
> sometimes not.

This use case is *not* affected by the recent changes at all. Whether mail
*automatically* determined as junk is marked as read is already controlled by a
preference. What bug 220933 introduced is that when you *manually* mark a
message as junk, it gets marked as read in the same step.
My usage issue is that I mark messages as junk to get the out of my Inbox. Then
later I go into the junk folder and report the unread messages to Spamcop. Now,
with this issue, I have no way of knowing which spams I have already reported.
The only way is to either drag them to the junk folder one by one, or be forced
not to remove them from my inbox until after I report them to Spamcop.
==> filters
Assignee: general → nobody
Component: General → MailNews: Filters
Product: Mozilla Application Suite → Core
QA Contact: general
Version: unspecified → Trunk
*** Bug 311814 has been marked as a duplicate of this bug. ***
This patch introduces a new pref called
"mailnews.ui.junk.manualMarkAsJunkMarksRead" that defaults to true (= the
current behaviour) and can be changed in Thunderbird's "Advanced
Configuration".
Assignee: nobody → jens.b
Status: NEW → ASSIGNED
Attachment #199602 - Flags: review?(bienvenu)
Attachment #199602 - Flags: review?(bienvenu) → review+
Updating code comments; carrying over r=bienvenu.
Attachment #199641 - Flags: review+
Attachment #199602 - Attachment is obsolete: true
Comment on attachment 199641 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v2

Dan, can you sr this short patch? It restores 1.0.x behaviour (via hidden
pref).
Attachment #199641 - Flags: superreview?(dmose)
Comment on attachment 199641 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v2

>+  nsCOMPtr<nsIPrefBranch> prefBranch(do_GetService(NS_PREFSERVICE_CONTRACTID));
>+  if (prefBranch)
>+  {
>+    prefBranch->GetBoolPref("mailnews.ui.junk.manualMarkAsJunkMarksRead",
>+                            markingJunkMessagesRead);
>+  }

This isn't correct XPCOM usage.  Instead, use the two-argument form of
do_GetService, and then check the second argument using NS_SUCCEEDED() or
NS_FAILED().

sr=dmose with that fixed.
Attachment #199641 - Flags: superreview?(dmose) → superreview+
Adressing dmose's comment, carrying over r=bienvenu and sr=dmose.
Attachment #199641 - Attachment is obsolete: true
Attachment #200125 - Flags: review+
Attachment #200125 - Flags: superreview+
Checking in mailnews/mailnews.js;
/cvsroot/mozilla/mailnews/mailnews.js,v  <--  mailnews.js
new revision: 3.253; previous revision: 3.252
done
Checking in mailnews/base/resources/content/mailCommands.js;
/cvsroot/mozilla/mailnews/base/resources/content/mailCommands.js,v  <-- 
mailCommands.js
new revision: 1.100; previous revision: 1.99
done
Checking in mailnews/base/src/nsMsgDBView.cpp;
/cvsroot/mozilla/mailnews/base/src/nsMsgDBView.cpp,v  <--  nsMsgDBView.cpp
new revision: 1.226; previous revision: 1.225
done
Checking in mail/base/content/mailCommands.js;
/cvsroot/mozilla/mail/base/content/mailCommands.js,v  <--  mailCommands.js
new revision: 1.24; previous revision: 1.23
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

This is a low-risk patch that allows users to restore the 1.0.x behaviour. I'd
very much like to have this in 1.5, because otherwise Thunderbird will be
broken for those who don't want their mails marked read when marking as junk
(manually).
Attachment #200125 - Flags: approval1.8rc1?
Verified on official trunk nightly build 20051020 (Windows); both marking via
junk column and toolbar/context menu work as specified for the pref being true
and false.
Status: RESOLVED → VERIFIED
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

I'm afraid it's too late for non critical changes for the branch.
Attachment #200125 - Flags: approval1.8rc1? → approval1.8rc1-
Regression, or have I just been asleep at the wheel? In Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051209 MultiZilla/1.8.1.0u SeaMonkey/1.5, no matter how my pref was set, the blasted junk status also toggled the read status. Was the patch not checked into the 1.9 branch?

Lewis

*** Bug 319865 has been marked as a duplicate of this bug. ***
I confirmed that the option was turned OFF in the UI. Upon noticing the behavior, I then opened the preferences editor, and to my surprise, mailnews.ui.junk.manualMarkAsJunkMarksRead was defaulted to true. Once I manually toggled it, it respected the option. The question, therefor, is why wasn't the UI in sync with the prefs.js?

Lewis

(In reply to comment #26)
> I confirmed that the option was turned OFF in the UI. Upon noticing the
> behavior, I then opened the preferences editor, and to my surprise,
> mailnews.ui.junk.manualMarkAsJunkMarksRead was defaulted to true. Once I
> manually toggled it, it respected the option. The question, therefor, is why
> wasn't the UI in sync with the prefs.js?

There is no UI for this pref. The option "Mark messages determined to be junk as read" applies to the automatic classification, not manual marking. See comment 11 and comment 15.
(In reply to comment #27)
> (In reply to comment #26)
> > The question, therefor, is why
> > wasn't the UI in sync with the prefs.js?
> 
> There is no UI for this pref. The option "Mark messages determined to be junk
> as read" applies to the automatic classification, not manual marking. See
> comment 11 and comment 15.
> 
You are so right, Jens; and my apologies to everyone for the bug spam. I should have refreshed my memory before posting my comment #26. Perhaps we should clean up the UI so that this is clear (a separator bar or something, dividing the automatic settings from the manual ones). I realize that it is listed closer to the automatic settings, but still, until close examination, it would not be apparent to the user. In fact, we may even want to be able to set these two options independently (if there is/are bug/bugs for this UI stuff of which you are aware, please advise).

Note that these latest comments invalidate my observation in comment #24, as evidently, the pref was defaulted to true at that point.

Lewis
*** Bug 322978 has been marked as a duplicate of this bug. ***
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

This didn't make it for 1.5, but it would be nice to fix this regression with a maintenance release.

- Has been on trunk for over two months now with no known regressions.
- Patch summary: introduces a new hidden pref that makes the behaviour previously introduced by bug 220933 optional (i.e. lets users revert to 1.0 behaviour)
- Risk: very low, patch only adds pref checks and if-blocks around existing code.
- Testcase: see comment #0.
Attachment #200125 - Flags: approval1.8.0.2?
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

not for the security release
Attachment #200125 - Flags: approval1.8.0.2? → approval1.8.0.2-
I just installed SeaMonkey 1.0 to replace Mozilla 1.7.12, and I am having this problem. I even added the mailnews.ui.junk.manualMarkAsJunkMarksRead Prefs key, set it to FALSE, and restarted SeaMonkey. I verified the key is still there, and still set to FALSE, but the problem remains. When I manually set a message to Junk, it is marked as READ.
(In reply to comment #32)
> I just installed SeaMonkey 1.0 to replace Mozilla 1.7.12, and I am having this
> problem.

The code was checked in to the trunk, so it won't appear in Seamonkey 1.0.x or Thunderbird 1.5.x releases, unless Scott gives approval for a branch checkin. Unfortunately, there is no workaround for you.
*** Bug 327887 has been marked as a duplicate of this bug. ***
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

Scott, this would be great to have in 2.0 (hidden pref to restore Thunderbird 1.0 behaviour, see comment 21). Can we land this on the 1.8 branch?
Attachment #200125 - Flags: approval-branch-1.8.1?(mscott)
Comment on attachment 200125 [details] [diff] [review]
introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]

yup, this would be good to have. thanks for nominating.
Attachment #200125 - Flags: approval-branch-1.8.1?(mscott) → approval-branch-1.8.1+
Whiteboard: checkin needed (1.8 branch)
Attachment #200125 - Attachment description: introduce 'manualMarkAsJunkMarksRead' pref, v3 → introduce 'manualMarkAsJunkMarksRead' pref, v3 [checked in on trunk]
Timeless checked this in on the branch a little while ago.
Keywords: fixed1.8.1
Whiteboard: checkin needed (1.8 branch)
Target Milestone: --- → mozilla1.8.1
Version: Trunk → 1.8 Branch
*** Bug 343038 has been marked as a duplicate of this bug. ***
*** Bug 349312 has been marked as a duplicate of this bug. ***
*** Bug 338648 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.