545504 - Pref for whether or not deleted messages get marked as read (e.g. when moved to trash)

Status: NEW

(Thunderbird :: Preferences, enhancement)

Description

[Jeff Beckley]

Currently Thunderbird marks messages as read when they are deleted.  Some users would like the ability to leave the messages as unread when they are deleted.

One organizational scheme that would take advantage of this is that some people use their Trash mailbox as a holding place for non-important messages (i.e. not worthy of filing in to a separate mailbox to keep forever), but have two levels on "non-importance".  One level is messages that are so non-important that they were deleted before they were even read, and another level is messages that were read but non-important enough to file away in a separate mailbox.  In this scenario it's nice to differentiate between the two because the Trash mailbox can be pruned to delete the unread messages but leave the read ones as they may have some need to be viewed again at a later time.  The Trash mailbox is a convenient place to do this because of the ease of deleting messages.

I know that Move to Trash will not mark as read, but that's a less convenient and more time consuming way to delete the messages.

Of course the pref would default to marking messages as read when deleting as that's the behavior most users want.

Comment 1

[Jeff Beckley]

Attachment: Pref added and used

Comment 2

[David :Bienvenu]

Jeff, I suspect that IMAP will still mark deleted messages as read - have you tried that?

Comment 3

[Jeff Beckley]

(In reply to comment #2)
> Jeff, I suspect that IMAP will still mark deleted messages as read - have you
> tried that?

It does work fine with IMAP when you use the Move to Trash on delete option.  If the delete pref is set to Remove immediately then it doesn't matter because the message disappears right away.  If the pref is set to Mark as deleted, then it does get marked as unread regardless of the deleteMarksRead pref.  Not sure what to do in this last case.  I could see it either ignoring the deleteMarksRead pref or honoring it.  Mark as deleted in IMAP is such a different beast.

Comment 4

[Jeff Beckley]

(In reply to comment #3)
> If the pref is set to Mark as deleted, then
> it does get marked as unread regardless of the deleteMarksRead pref.

That should have been "read" not "unread".

Comment 6

[Mark Banner (:standard8)]

So over in bug 465116 we won't fixed pretty much exactly the same patch as this, as the demand for it didn't seem worth having a hidden preference.

As I said in bug 465116 comment 18:

> 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.

Comment 7

[Mark Banner (:standard8)]

Comment on attachment 426345 [details] [diff] [review]
Pref added and used

Cancelling reviews until there's a response to comment 6.

Comment 10

[jwq]

(In reply to Mark Banner (:standard8) from comment #6)

 I object to the change. I know I'm late to the party, but we all know the reason for that.

 Reading "... Thunderbird does not want..." as "... the Thunderbird devs do not want..." I'm compelled to point out that I, as a user, do not want arbitrary changes to the UI forced upon me by devs (no matter how great and sensible the devs think the arbitrary changes are). This bug is submitted to correct for this "failure in development".

 After the UI behaviour is silently changed I'm not sure why you expect to hear from people - there's a cost associated with objecting to these changes in a way you will notice. I don't accept this argument as a valid reason for not accepting the request for a hidden pref.

 Similarly, the suggestion of an extension as the solution to this request has significant costs associated with it: such an extension will likely be easily broken and thus require someone's time for ongoing maintenance. Unless you're volunteering your own time to write and maintain such an extension, I don't accept this argument as a valid reason for not accepting the hidden pref.

 I believe those were the two arguments for not implementing the requested hidden pref to correct this "failure in development" and I regret I am unable to accept them as valid. May we please have the hidden pref so we can restore the UI to the way it used to be?

BTW, these situations (there are, alas, many examples) can be avoided in the future by not making arbitrary changes to the UI defaults. In the future if you want to make a UI change perhaps you could implement it as a hidden pref to allow "great and sensible" changes without affecting the defaults?

Comment 11

[Blake Winton (:bwinton) (:☕️)]

Would you be satisfied if we added the hidden pref, got numbers on how many people used it, and then removed it if fewer than, say, 2% of our userbase switched it on?  (I'm not saying that we will, I'm just asking if you would agree to that.)

(I also object to your characterization of the UI changes as "arbitrary".  They're literally the opposite of arbitrary, both in that they have been agreed to by a number of people (at the minimum the developer who implemented it and the reviewer who reviewed it), and in that they are working towards a future plan or (in this case) along a set of guidelines.)

Thanks,
Blake.

Comment 12

[jwq]

 It seems to me to be wasteful of resources to add of a hidden pref of such precarious status that it could be removed at some later date, effectively by random chance, particularly under the circumstances that:

  i. The setting requested here was the original default setting;
 ii. The default setting, which was perfectly acceptable as it was, was changed;
iii. Objections were raised to this change to the default settings;
 iv. Some considerable time has now passed after the original change and objections.

Note, in particular, that the new default setting actually causes data loss: the read status information is removed from deleted messages. The core of this request to restore the original default setting is to remedy this data loss.

 After such a long time, I think it's questionable whether people are going to search out a hidden pref solution to a data loss problem which was, in the first place, caused by a change to a perfectly acceptable default setting.

 What you suggest would have been the best way to resolve Bug 211439 - by adding capability rather than changing the default setting.

 Under the circumstances we now find ourselves in a difficult situation of having to rectify a problem caused by the change to the default. The best solution is to add a pref (hidden or exposed) controlling "mark read on delete" /and/ restore the original default setting. The second best solution is to add the pref only and leave the changed dataloss default as is. The worst "solution" is, of course, to do nothing.

 Again, and I can't stress this enough, this is the way Bug 211439 should have been handled - by adding something to TB rather than simply changing behaviour which was perfectly acceptable as it was.

I'm going to take the liberty of adding the dataloss keyword to this bug, because data is actually being lost.

Comment 13

[Blake Winton (:bwinton) (:☕️)]

I think, based on https://bugzilla.mozilla.org/describekeywords.cgi#dataloss, that adding the dataloss keyword is a bit of a stretch.  Arguing that the read status of deleted messages is critical data to many Thunderbird users seems like it would be a tricky thing to do.

So, I worry about Thunderbird flipping back and forth between two options, since that seems like a way to annoy everyone.  (Granted, it would annoy everyone equally, but if we're going to annoy people, I feel it would be better to annoy fewer of them.)  Furthermore, removing this would leave us with no way to delete messages while marking them as read; whereas currently you can delete messages without marking them as read by using the "Move to Trash" functionality.

But those two points only eliminate your first solution.  So, let me ask a variant of my previous question: Would you be satisfied if we added a (non-hidden) pref set to the current default (a.k.a. your solution 2), got numbers on how many people used it, and then removed it if fewer than, say, 2% of our userbase switched it on?

And while I agree that from your point of view, the worst solution would be to do nothing, even that has some obvious benefits, and is likely to be what happens unless someone can convince a community member to step up and help fix this.  (I'll be more than happy to review and ui-review any patches, but I sadly don't have the time to write them myself, nor do any of the people I manage.)

To that end, I notice that you've been helping out Mozilla for quite a few years now.  Would you like to give this feature a shot?  It's all javascript, shouldn't be that hard, and I'll be here to help you as much as I can…

I'm explicitly not commenting on what should or should not have happened in bug 211439, because it was both filed and fixed long before I was made UX Lead.  (Perhaps also because in the future, it's likely I'll make some decisions to change behaviours that some people think are perfectly acceptable, without offering fallbacks.  Tabs-on-top, for instance, is coming up soon.)

Thanks,
Blake.

Comment 14

[Blake Winton (:bwinton) (:☕️)]

After re-reading my comment, I've realized that I mis-read your answer.  I think, based on what you said in comment 12, that you would consider implementing any pref, hidden or not, to be a waste of resources if it had a chance of removal.

I believe that if there is a feature that only a small percentage of our users find useful, then we should remove that feature (or, more considerately, turn it into an add-on), so that we can keep Thunderbird's default preferences as easy to understand as possible.

It's under that belief that I proposed the 2% test for whether or not to keep this addition, but if you feel there's a fairer test for whether or not we should include a feature; a test which also satisfies my desire to not put everything in Thunderbird, and to allow it to grow and change to meet the needs of the future; I would certainly be willing to discuss that with you.

Thanks,
Blake.

Comment 15

[jwq]

 Removing dataloss keyword. I'd forgotten the /critical/ part of its definition and, you're right, this is by no means critical.

 It's the implementation of a hidden pref that I think would be a waste of resources if its retention were based on usage. An exposed pref is much more likely to be used, so I'd be happier with that being retained based on usage. I'll take some time to think over the other matters you raised.

Comment 16

[John Brooks]

What's the status on this? 

I'd like the option to not mark mail as read when moving/trashing it.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to John Brooks from comment #16)
> What's the status on this? 

It doesn't exist, and given its history I suspect is unlikely to be implemented

Comment 18

[jwq]

I believe that the invitation (comment 13) remains open for someone sufficiently motivated to implement a pref to control this. The status is perhaps more accurately "nobody is working on this but it's OK to take it and work on it".

 I see that there are a lot more requests and support for this pref to be implemented than I can see requests and support for the original change to the default. On the strength of this, I don't agree with Standard8's addition to the whiteboard - but I'm hesitant to remove it myself.

The related SeaMonkey RFE is Bug 274022.

Comment 19

[Wayne Mery (:wsmwk)]

This belongs in prefs component. 

I can't say I've ever seen it requested in any support forum.  This and several bug comments weigh into my personal opinion of not currently being in favor of an exposed or a hidden pref.  But anyone is welcome to draft a patch for consideration or create an addon


> but I'm hesitant to remove it myself.

Indeed, keeping it is giving due deference to the the assessment of a developer and (former?) module owner

Comment 20

[Jim Porter (:squib)]

I have to say, I'm not entirely sure why deleting marks as read in the first place. What benefit does it serve? I can think of two:

1) Send a "read receipt" to the user when deleting a message if you don't have "automatically mark read" on.
2) Fix issues with the message count in the folder tree, similar to how we mark drafts *un*read.

(1) is dubious, since then we'd also be sending those receipts to spam that you deleted. We shouldn't be doing that. (2) is also a bad reason to have this behavior, since the proper solution is to fix the folder tree.

I wouldn't support an option for this (we need fewer options, not more), but I *would* support restoring the old behavior.

Comment 21

[Wayne Mery (:wsmwk)]

https://support.mozilla.org/en-US/questions/1205792 suggests another reason for doing this - that it is difficult to distinguish messages that have been accidentally moved to trash.

Some historical info ... Bug 211439 comment 0 "Ideally, undelete would restore the unread mark, if necessary." unfortunately didn't happen.


(In reply to Jim Porter (:squib) from comment #20)
> 
> I wouldn't support an option for this (we need fewer options, not more), but
> I *would* support restoring the old behavior.

I don't wish to be revisionist, but I wonder how much calcuation went into Bug 211439

Comment 24

[Mark Clements]

I, too, find this behaviour very strange and undesirable.

Aside from being unintuitive, there is one important use-case that doesn't seem to have been mentioned above, which happened to me recently and which was very frustrating:

== Steps to reproduced ==

1. Select some messages, some of which are unread.
2. Press delete.
3. Press Ctrl-Z to undo the action.

Most recently, this arose due to the intervention of my cat at step #2. However, I have encountered it in normal usage as well, where I have changed my mind or realised I had selected the wrong set of messages.

== Expected behaviour ==

The messages are restored to the inbox, exactly as they were prior to the delete.

== Actual behaviour ==

The messages are restored the the inbox but they are now all marked as read; the data relating to the read/unread state of the messages has been lost.

Comment 25

[Mark Clements]

Another data point: This doesn't seem to happen if you delete items from the search results window. In this case, the read/unread flag state is retained, so TB is not even internally consistent with regards to this functionality.

Comment 26

[Andy Lankin]

How about a user option to not bold the Deleted folder name and not display the number of Unread messages in the Folder Pane views? That way, I wouldn't have my eye drawn unnecessarily to the Deleted folder when scanning the folder list, if that's what I choose.

Comment 27

[santiago-berlin]

Unbelievable! This bug is seriously 14 years old!??

This is a basic and important bug!!

Marking messages read upon deletion leaves me with a totally unsorted trashbin, which makes it difficult / impossible to free up space by just deleting the most unimportant (even unread) messages!!

Could you please finally do something about that??

Comment 28

[jcc]

Me too! I can't believe this problem still exists. I absolutely don't know why mail I haven't read is automatically marked read when I trash it. Just leave it alone please. I often need to sort through deleted mail to find something I didn't read.

Comment 29

[bodo.pfelzer]

For me it's the other way round. A few weeks ago my Thunderbird (115.4.1) started to not mark mails as read on delete. As I do not officially read SPAN, I only delete it. Now I am surprised to find unread mails in the Trash folder. I then have to read the SPAN again and mark it explicitly. I would like to be able, to configure the old behaviour.

Comment 30

[jcc]

(In reply to bodo.pfelzer from comment #29)

For me it's the other way round. A few weeks ago my Thunderbird (115.4.1) started to not mark mails as read on delete. As I do not officially read SPAN, I only delete it. Now I am surprised to find unread mails in the Trash folder. I then have to read the SPAN again and mark it explicitly. I would like to be able, to configure the old behaviour.

If it's in your trash, why would you want to view it again unless it's something you haven't read in which case it helps to separate the stuff you read from the stuff you haven't. I like having the unread mail still marked as unread for those times I accidentally deleted something that I thought was spam but turned out to be important. I delete trash that's more than a month old but anything less than a month might be valuable to keep until I know it's not needed. It just helps if what was never read is marked accordingly.

Comment 31

[bodo.pfelzer]

(In reply to jcc from comment #30)

(In reply to bodo.pfelzer from comment #29)

For me it's the other way round. A few weeks ago my Thunderbird (115.4.1) started to not mark mails as read on delete. As I do not officially read SPAN, I only delete it. Now I am surprised to find unread mails in the Trash folder. I then have to read the SPAN again and mark it explicitly. I would like to be able, to configure the old behaviour.

If it's in your trash, why would you want to view it again unless it's something you haven't read in which case it helps to separate the stuff you read from the stuff you haven't. I like having the unread mail still marked as unread for those times I accidentally deleted something that I thought was spam but turned out to be important. I delete trash that's more than a month old but anything less than a month might be valuable to keep until I know it's not needed. It just helps if what was never read is marked accordingly.

An unread message says "Pay attention to me". I deactivated the option "Automatically mark messages as read". So a message in my INBOX stays unread until I explicitly process it (either by marking as read or by deleting it). Now the message is in Trash but it still says "Pay attention to me". Why would you want to delete a message before reading it? But perhaps the new behaviour would be less annoying, if the Trash folder would never be marked as containing unread messages in the overview.

Comment 32

[jcc]

An unread message in the trash says that it was never paid attention to which is exactly what I need in the event that it was deleted by accident or oversight. After a month they all get deleted from the trash, read or not. I delete lots of stuff I don't read because of the volume of mail I get. I only read what appears to be important at the time I get it and delete the rest.