465116 - "Move to Trash" now marks as read

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081115 SeaMonkey/2.0a2pre - Build ID: 20081115000503

Until yesterday, moving emails to Trash didn't change their read/unread status. I used to put that to profit by marking my mail unread before moving them to Trash, so that I could see at a glance how many items were in the dustbin.

Now suddenly, whenever I move emails to trash they are automagically marked as read, defeating my purpose.

Notice that opinions are not unanimous in this respect:
- In favour of automagically marking as read: bug 211439, bug 380052
- In favour of automagically marking as unread: bug 420453
- In favour of not changing read/unread status on move to trash (i.e., keep the former behaviour unchanged): this bug

Maybe a preference would be in order (I tried to find one in about:config, and failed). Otherwise, I believe that not changing the read/unread status would allow users to mark as read, or as unread, immediately before moving to Trash, and thus not interfere unduly with their freedom.

Comment 1

[Robert Kaiser]

IMHO, this bug is WONTFIX as it's the wanted behavior bug 463849 introduced, but CCing the patch creator and the reviewers here.

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> IMHO, this bug is WONTFIX as it's the wanted behavior bug 463849 introduced,
> but CCing the patch creator and the reviewers here.

Why not make it optional? This bug 463849 smells of "I don't like it on my system, therefore you can't have it on yours". If Karsten wants all his mail to be marked unread when moved to Trash, that's OK for me, but please let me make the opposite choice.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #0)
> Notice that opinions are not unanimous in this respect:
> - In favour of automagically marking as read: bug 211439, bug 380052
> - In favour of automagically marking as unread: bug 420453

Actually I think there's a contradiction between the subject and initial comment of  bug 420453. Given that the bug report is much older than the respective change in TB (bug 211439) it's quite likely bug 420453 is another one in favor of mark as read (that is not to belittle your position, just my comment to that bug).

> Maybe a preference would be in order (I tried to find one in about:config, and
> failed). Otherwise, I believe that not changing the read/unread status would
> allow users to mark as read, or as unread, immediately before moving to Trash,
> and thus not interfere unduly with their freedom.

Obviously the current behavior is an improvement for people like me, else I wouldn't have come up with it in the first place. You can (and I have) add a column for the total amount of messages in any folder, including the Trash. Anyway if you want to have the old behavior back I'm fine with a pref (if you ask me - not that my opinion is authoritative). Since you are the requester, which kind of pref are you thinking about? Preferences window, normal or hidden? I'd say a normal pref would be appropriate.

(In reply to comment #2)
> 
> Why not make it optional? This bug 463849 smells of "I don't like it on my
> system, therefore you can't have it on yours".

Actually it was "TB changed it and I think it makes sense, let's port it".

> If Karsten wants all his mail to
> be marked unread when moved to Trash, that's OK for me, but please let me make
> the opposite choice.

Did I already say I'm all for choice? :-)

Comment 4

[Tony Mechelynck [:tonymec]]

What kind of pref? In prefwindow would be ideal, in about:config (visible by default) would be tolerable, about:config (default unset) would not be acceptable. Let's say (for a first shot at it, there are other possibilities)
mail.moveToTrashMarksRead (integer)
  0  move to trash doesn't change read/unread
 -1  (or any negative value) move to trash marks as unread
  1  (or any positive value) move to trash marks as read.
For the current new behaviour ("yours") 1 would be the default, to get back to the former it could be set to 0, to spare me the "mark as unread" step I could even set it to -1.
Of course an appropriate entry in http://kb.mozillazine.org/Mail_and_news_settings and possibly a new page http://kb.mozillazine.org/Mail.moveToTrashMarksRead would be necessary but unlike the prefs patch I can write them up myself once this bug lands (if ever it does).

Now let's compare the previous behaviour with the current one. Between selecting one or more emails and hitting Del, you're spared exactly one keypress (m for toggle read/unread status), sometimes zero (if all are already read), at most two (toggle twice, maybe, if some are read and others not). But I have to either move to trash by drag-dropping with the mouse (which is IMHO a loss compared to my former m then Del) or Alt+m (Message) m (Move) Up (Local Folders) Right (Submenu) Down Down Down Down (Trash) Enter (Execute). IOW, in order to spare yourself just one keypress (on average) you (or the Thunderbird guys) force me to use nine instead of two! Ah, well...

Comment 5

[Karsten Düsterloh]

> Why not make it optional?

Well, in theory, we can. But is it really worth it?

> This bug 463849 smells of "I don't like it on my system, therefore you can't
> have it on yours".

Please readjust your nose, as that's not the case. :)
I usually don't base my decisions on _my_ usecase, since I'm well aware that my usage is usually weird. ;-)

The real question here is: Why do I delete mail?
Because I don't need it anymore.

And it doesn't make any sense to make the UI tell you "hey, you didn't read certain messages you deleted", because, well, you deleted them. On purpose.

> I used to put that to profit by marking my mail unread before moving 
> them to Trash, so that I could see at a glance how many items were in
> the dustbin.

If I understand that right, you have hidden the "Unread/Total/Size" columns of the folder pane, so (only) unread(!) numbers are shown behind the folder name.

Honestly, this is just abusing "unread" to symbolize "deleted" - 
that's no real objection to the change made...

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to comment #5)
[...]
> If I understand that right, you have hidden the "Unread/Total/Size" columns of
> the folder pane, so (only) unread(!) numbers are shown behind the folder name.
> 
> Honestly, this is just abusing "unread" to symbolize "deleted" - 
> that's no real objection to the change made...

The problem with that "Total" column is that it is a separate column spanning the whole height of the mail & news left pane, and some of the numbers in it (total number of posts in a newsgroup) are very big (currently 92846 in mozilla.support.firefox and 73148 in mozilla.support.thunderbird). In addition, when I display that column, there is a column of totally white space slightly more than 1cm wide between the name of the folder/group (with number unread if any) and the total number of messages there. As a result, my newsgroup names shrink to the point where they become hard to decipher (e.g. "m.d.a.s...y(122)" for mozilla.dev.apps.seamonkey). I see that I can shrink that totals column, but then its title becomes "T..." which is far from meaningful.

OTOH, the "number unread", in parentheses after the folder or newsgroup name, is already there (and needed in non-trash folders); if I want to have it show, in the particular case of Trash, how many are there (so that if I see a three-digit number it may be time to empty trash), I don't call that "abuse".

Now for my use cases, I have two:
- Spam gets moved to Trash without reading. Most of it was detected by the Junk Mail controls and in that case it is still marked unread.
- Bugmail etc. I move to trash after reading it and possibly acting upon it.

So it's not at all surprising to have unread mail in the dustbin: spam is a prime example.
Note: When moving mail to junk manually (from Inbox without reading), the default is to mark it automagically as read. If I follow your reasoning, using "read" to mean "manual junk" is just abusing it too. However in this case there is a preference to suppress that change. Why not in the other case?

Comment 7

[Karsten Düsterloh]

(In reply to comment #6)
> Note: When moving mail to junk manually (from Inbox without reading), the
> default is to mark it automagically as read. If I follow your reasoning, using
> "read" to mean "manual junk" is just abusing it too. However in this case there
> is a preference to suppress that change.

Okay, _that's_ a good point.

Comment 8

[Steve Midgley]

A similar conversation is going on for Thunderbird - this message is to just cross link the conversations in both directions: Bug 475911.

Comment 9

[Tony Mechelynck [:tonymec]]

(In reply to comment #8)
> A similar conversation is going on for Thunderbird - this message is to just
> cross link the conversations in both directions: Bug 475911.

That Thunderbird bug is for Windows => setting Platform to All.

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

Since I was the one who "broke" it, let me make another attempt to enable choice here...

Thinking about it again, "read" is really a special case. Depending on the user's habit, "read" can either mean "read" or "flagged"/"unfinished"/"to do". 

There is an actual flag feature (I), but I doubt many are using it or even noticed it. It doesn't make the message line or folder bold, doesn't change any message counts, nothing. Just a flag that can easily be missed. A dead feature, if you ask me.

"Read" on the other hand is highly visible. I for example am one of those who completely disabled marking messages as read automatically. I either delete messages or change the read status manually (M/R). When deleting, I want the message to be gone. That's why I mostly use Shift+Delete and keep emptying trashes regularly. I understand that people what to use the read status in the trash folder, too, though. I wouldn't call that misuse--for the same reasons why I use it in normal folders.

I really think we should enable choice here. We don't have to make it easy (provide UI) or change the default, but we IMO should at least make it possible to change the behavior.

So, again, Karsten and Neil, would you be OK with a simple pref check in MsgDeleteMessage that determines whether MarkSelectedMessagesRead should be called or not? No re-introduction of the gMarkViewedMessageAsReadTimer check, no change to the Junk marking behavior. Just a pref to not mark as read upon deletion. I'd leave it up to you whether to have it visible in about:config by default or not (i.e. whether to make it a hidden pref or not).

Comment 12

[[e-mail]]

I'd have no problem with a pref to control read behaviour on delete...
but I'd like it to default to mark as read ;-)

Comment 13

[Karsten Düsterloh]

(In reply to comment #12)
> I'd have no problem with a pref to control read behaviour on delete...
> but I'd like it to default to mark as read ;-)

Seconded.
And since mailnews.ui.junk.manualMarkAsJunkMarksRead has default value, mailnews.ui.deleteMarksRead (better suggestions?) should as well.

Comment 14

[Tony Mechelynck [:tonymec]]

(In reply to comment #13)
> (In reply to comment #12)
> > I'd have no problem with a pref to control read behaviour on delete...
> > but I'd like it to default to mark as read ;-)
> 
> Seconded.
> And since mailnews.ui.junk.manualMarkAsJunkMarksRead has default value,
> mailnews.ui.deleteMarksRead (better suggestions?) should as well.

Well, for the former there is a UI: "Edit => Preferences => Mail & Newsgroups => Junk & Suspect Mail => Global Junk Mail Settings => Mark messages as read: [x] When I manually mark them as junk", so why not another checkbox, maybe "Edit => Preferences => Mail & Newsgroups => Message Display => General => [x] Mark messages as read when I 'delete' them into the Trash" (or something)? (Note: Moving to Trash by a "Move" command currently doesn't change the read/unread setting, and I don't want to change that behaviour.)

Comment 15

[Karsten Düsterloh]

> why not another checkbox

We'd provide a pref, and we won't hide it (aka have a default value) - but I don't think that this rather obscure feature is significant enough to warrant a UI.

Comment 16

[Jens Hatlak (:InvisibleSmiley)]

Attachment: add pref

For this bug and TB bug 420453, pref only.

Comment 17

[Daniel B.]

(In reply to comment #5)
> And it doesn't make any sense to make the UI tell you "hey, you didn't read
> certain messages you deleted", because, well, you deleted them. On purpose.

That's not really valid.  

First of all, we don't know that the user deleted the messages on purpose 
and not by accident:

That whole point of having the Trash folder (having the two-step delete 
process) to be able recover from accidental deletion (and similar 
cases of changing one's mind), right? 


And why wouldn't it make sense to have the UI tell you whether you read
the messages or not?  It can tell you everything else about the message 
(From header, body, flags, etc.) (except what folder is was in before
you deleted it to the Trash folder).  

In fact, the read/unread status might be the first bit of information you
want to have in order to recover from an accidental or accidentally excessive 
deletion.  Imagine meaning to select some read messages, accidentically 
selecting more, and deleting before recognizing your selection error.  If you 
could see which freshly moved messages were not read, you'd know at least 
some of the messages you'd want to pull back out of the Trash folder.)

Comment 18

[Mark Banner (:standard8)]

Comment on attachment 454152 [details] [diff] [review]
add pref

Having thought about this for a bit we've decided that Thunderbird does not want the hidden pref. There seems to be very little demand for it - we've not had any significant numbers of objections to the change in the mode of operation, and it is something that I believe can be implemented in an add-on, or hooks could be added so it may be implemented as an add-on.

The other advantage of an add-on is that if a user is having an issue with the alternate functionality, then running in safe mode (which we normally request users to do), would show the normal behaviour and we could narrow down the fault much easier than a hidden pref.

This decision does not affect SeaMonkey - if SeaMonkey still wants the hidden pref, that is fine, but please consider moving the pref to a SeaMonkey specific file or at least wrapping it in an ifdef MOZ_SUITE.

Comment 19

[Jens Hatlak (:InvisibleSmiley)]

Attachment: SM-only patch [Checkin: comment 20]

I guess I could just have gone ahead given the r+ by Mnyromyr but to be sure I'm re-requesting review. Please check comment 18 and if you didn't change your mind, also the pref position in browser-prefs.js (and yes, we should really have a MailNews-specific pref file!).

Comment 20

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 470016 [details] [diff] [review]
SM-only patch [Checkin: comment 20]

http://hg.mozilla.org/comm-central/rev/952f741db45e

Comment 21

[Tony Mechelynck [:tonymec]]

Bug 545504 is the Thunderbird bug to add a pref. The SeaMonkey one is bug 274022.

Comment 22

[jwq]

(In reply to Tony Mechelynck [:tonymec] from comment #21)
> Bug 545504 is the Thunderbird bug to add a pref. The SeaMonkey one is bug 274022.

 I'm not sure how this bug differs from Bug 274022? That is to say, why is Bug 274022 still open and not marked resolved as a duplicate of this bug?

 That said, I am sure that in Bug 545504 I wanted to add this bug as a See Also because of the relevant information in Comment 18 and the example of how the pref was implemented in SeaMonkey. If I understand the field correctly, that is the right way to use it. I wasn't expecting or intending the reciprocal setting of "See Also Bug 545504" on this bug, which isn't appropriate or desirable. Is there no way to set a unidirectional "See Also"?

Comment 23

[Tony Mechelynck [:tonymec]]

(In reply to jwq from comment #22)
> (In reply to Tony Mechelynck [:tonymec] from comment #21)
> > Bug 545504 is the Thunderbird bug to add a pref. The SeaMonkey one is bug 274022.
> 
>  I'm not sure how this bug differs from Bug 274022? That is to say, why is
> Bug 274022 still open and not marked resolved as a duplicate of this bug?
> 
>  That said, I am sure that in Bug 545504 I wanted to add this bug as a See
> Also because of the relevant information in Comment 18 and the example of
> how the pref was implemented in SeaMonkey. If I understand the field
> correctly, that is the right way to use it. I wasn't expecting or intending
> the reciprocal setting of "See Also Bug 545504" on this bug, which isn't
> appropriate or desirable. Is there no way to set a unidirectional "See Also"?

IIUC, this bug (FIXED) is about avoiding marking mail as read whenever it is moved to Trash, while big 274022 (NEW) is about making that behaviour depend on a pref.

And no, if the "See also" bug is also at bugzilla.mozilla.org, the relation is bidirectional. If it's at another bugzilla, e.g. bugzilla.redhat.com or bugzilla.opensuse.org, then setting it here makes no automatic change over there, you have to do it manually.

To have a unidirectional pointer, just mention the other bug as "Bug nnnnn" in a comment. But then it isn't set in the bug header.

Comment 24

[jwq]

 While this discussion might be better in Bug 274022, it's started here so let's continue to its conclusion for the sake of non-fragmentation. In Comment 0 you request a preference and this bug was fixed by implementing a preference 'mailnews.ui.deleteMarksRead' and making the behaviour depend on it. That's what we both understand Bug 274022 to request, so the question remains: why is Bug 274022 still open and not marked resolved as a duplicate of this bug?

 Bidirectional "See Also" setting is not documented in the field help <https://bugzilla.mozilla.org/page.cgi?id=fields.html>, neither is the meaning of "other installations" to mean "other installations of bugzilla, e.g. bugzilla.redhat.com". A /lot/ of people are using the See Also field in the intuitively obvious way, to list in the heading area bugs which contain relevant information but don't constitute a dependent or blocking relationship.

 Which brings us back to where this started: In Bug 545504 I set "See Also Bug 465116", which set the reciprocal "See Also" here, which you then redirected from this bug to "See Also Bug 274022" which, and it's not obvious, /un-set "See Also Bug 465116" from Bug 545504/. I'd call that sufficient evidence that the mechanism is unusable enough to be called broken - probably something that should be filed as a bug against Bugzilla.

 In the meantime, is there a particular reason for this bug to list "See Also Bug 274022"?

 Is there any particular reason why this bug (FIXED) can't bear the reciprocal "See Also" set from Bug 545504?

Comment 25

[Tony Mechelynck [:tonymec]]

(In reply to jwq from comment #24)
>  While this discussion might be better in Bug 274022, it's started here so
> let's continue to its conclusion for the sake of non-fragmentation. In
> Comment 0 you request a preference and this bug was fixed by implementing a
> preference 'mailnews.ui.deleteMarksRead' and making the behaviour depend on
> it. That's what we both understand Bug 274022 to request, so the question
> remains: why is Bug 274022 still open and not marked resolved as a duplicate
> of this bug?

When I chenged the "See Also" settings, I checked the bugs' Summaries and not the details of the patch. Apparently I should have: if this bug was fixed by setting a pref, then bug 274022 is a dupe.
> 
>  Bidirectional "See Also" setting is not documented in the field help
> <https://bugzilla.mozilla.org/page.cgi?id=fields.html>, neither is the
> meaning of "other installations" to mean "other installations of bugzilla,
> e.g. bugzilla.redhat.com". A /lot/ of people are using the See Also field in
> the intuitively obvious way, to list in the heading area bugs which contain
> relevant information but don't constitute a dependent or blocking
> relationship.
> 
>  Which brings us back to where this started: In Bug 545504 I set "See Also
> Bug 465116", which set the reciprocal "See Also" here, which you then
> redirected from this bug to "See Also Bug 274022" which, and it's not
> obvious, /un-set "See Also Bug 465116" from Bug 545504/. I'd call that
> sufficient evidence that the mechanism is unusable enough to be called
> broken - probably something that should be filed as a bug against Bugzilla.

You could try, but I'd expect such a bug to be RESOLVED INVALID, or, if you REOPEN it, WONTFIX. AFAIK such behaviour is intentional, because if bug A is of sufficient permanent interest to be mentioned in the headers of bug B, then there might be a good reason for people interested in bug A to see what bug B is about. The fact that it isn't bidirectional for different installations is, I suppose, due to the fact that the code for one of these installations cannot make a change in another one, all the less so since the person making the change might not be subscribed to that other Bugzilla, or under a different name and/or address.
> 
>  In the meantime, is there a particular reason for this bug to list "See
> Also Bug 274022"?
> 
>  Is there any particular reason why this bug (FIXED) can't bear the
> reciprocal "See Also" set from Bug 545504?

All right, you've made your point. Bug 274022 can be RESOLVED DUPLICATE of this one, and the reason to make it a dupe of a later bug (and not vice-versa) is that the later bug contains the fix. And once it's marked as a dupe, it's "See Also" setting(s) can be ported to the bug it's a dupe of. I'll do it.