725445 - messages determined to be Junk are marked read irrespectively of the flag in the options

Status: RESOLVED DUPLICATE of bug 475914

(Thunderbird :: Folder and Message Lists, defect)

Description

[artem.glebov]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

1. Go to Options -> Security -> Junk and make sure the checkbox "Mark messages determined to be Junk as read" is not set;
2. Click on the Junk knob in the message list to mark it Junk.


Actual results:

The message is marked read.


Expected results:

The status of the message should remain unread.

Comment 1

[Hashem Masoud]

(In reply to artem.glebov from comment #0)
Go to Help ➙ Restart with Add-ons disabled and re-check.

Comment 2

[artem.glebov]

(In reply to Hashem Masoud from comment #1)
Did it. The same behaviour.

Comment 3

[:aceman]

This is problematic. I confirm the behavior you see in TB13.
However, I found this comments in the code:
// notes on marking junk as read:
// 1. there are 2 occasions on which junk messages are marked as
//    read: after a manual marking (here and in the front end) and after
//    automatic classification by the bayesian filter (see code for local
//    mail folders and for imap mail folders). The server-specific
//    markAsReadOnSpam pref only applies to the latter, the former is
//    controlled by "mailnews.ui.junk.manualMarkAsJunkMarksRead".
// 2. even though move/delete on manual mark may be
//    turned off, we might still need to mark as read

I can confirm that setting mailnews.ui.junk.manualMarkAsJunkMarksRead to 'false' does work fine, makes the message not be marked as read.
You can try that in Options->Advanced->General->Config editor .

Comment 4

[artem.glebov]

As I marked a few of the messages junk, I found out that now some of the incoming messages are marked junk automatically. I presume this means automatic (Bayesian?) filtering is now on. This was rather surprising to me, as I did not intend to switch the automatic filter on, I just wanted to do it manually. Perhaps, an option could be added to the Options to make this explicit.

Comment 5

[:aceman]

You can enable/disable automatic junk classification per account in the Account settings -> Junk settings.

Comment 6

[artem.glebov]

(In reply to :aceman from comment #5)
> You can enable/disable automatic junk classification per account in the
> Account settings -> Junk settings.

Thanks. The question is why it became enabled without asking me first.

Comment 7

[:aceman]

Maybe it is the default setting. Maybe it was always on just not marking anything until you started to train it.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #3)
> This is problematic. I confirm the behavior you see in TB13.
> However, I found this comments in the code:
> // notes on marking junk as read:
> // 1. there are 2 occasions on which junk messages are marked as
> //    read: after a manual marking (here and in the front end) and after
> //    automatic classification by the bayesian filter (see code for local
> //    mail folders and for imap mail folders). The server-specific
> //    markAsReadOnSpam pref only applies to the latter, the former is
> //    controlled by "mailnews.ui.junk.manualMarkAsJunkMarksRead".
> // 2. even though move/delete on manual mark may be
> //    turned off, we might still need to mark as read
> 
> I can confirm that setting mailnews.ui.junk.manualMarkAsJunkMarksRead to
> 'false' does work fine, makes the message not be marked as read.
> You can try that in Options->Advanced->General->Config editor .

Is the server-specific markAsReadOnSpam hidden?  I don't see it in the UI.

Comment 9

[Wayne Mery (:wsmwk)]

another example of confusion, which makes this bug a duplicate of bug 475914
mail.spam.markAsReadOnSpam                 is options | security | junk FOR bayesian automatic filtering
mailnews.ui.junk.manualMarkAsJunkMarksRead is hidden FOR manual marking, introduced by bug 306026

avoiding the confusion is the goal of bug 352428