Open Bug 328714 Opened 19 years ago Updated 1 year ago

Undo delete message marks message as read

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Platform:
PowerPC
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

People

(Reporter: elharo, Assigned: aceman)

References

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 When I delete a bunch of messages in the inbox window, and then change my mind and immediately undo, all these messages have been marked as read even though I haven't read them. This is particularly noticeable when I have the filters set to only show unread messages. In this case, it appears as if the Undo failed because the message sdon't return to the filtered view of the Inbox. Reproducible: Always Steps to Reproduce: 1.Select several unread messages. 2. Press delete 3. Edit/Undo Actual Results: Undeleted messages are marked as read Expected Results: Undeleted messages are marked as unread
QA Contact: front-end
Assignee: mscott → nobody
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported 2.0.0.x is version 2.0.0.16)
Whiteboard: closeme 2008-09-11
I haven't tried the latest nightly. I just verified that it still occurs in 2.0.0.16.
I just tested on Shredder Alpha 2 (trunk) myself, this doesn't seem to be an issue. 10.5.4 Leopard.
Keywords: qawanted
Whiteboard: closeme 2008-09-11
Gary, are you saying undo restores messages from trash for you in unread state? It doesn't work that way for me, which I think is by design. Perhaps Magnus is familiar with it.
Keywords: qawanted
(In reply to comment #4) > Gary, are you saying undo restores messages from trash for you in unread state? Yes, on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090120 Lightning/1.0pre Shredder/3.0b2pre I selected messages, unread, deleted them, undid, then they came back to inbox as unread. However, there was a certain level of wonkiness, sometimes they would fail to go back into inbox, much less been unread, but I suppose that's for another bug.
This problem still exists in 3.0b3pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090513 Shredder/3.0b3pre
1) Selected 3 messages from inbox and marked them unread. 2) moved to another folder and then reselected inbox (to prevent a selected email from becoming read via the preview pane) 3) cmd-a to select all 4) delete 5) go to trash, messages are now all read 6) cmd-a all messages, and cmd-z to undo 7) messages in inbox are still marked read. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090823 Shredder/3.0b4pre IMAP account
Lint can you provide imap logs ? (see https://wiki.mozilla.org/MailNews:Logging). Anything in Tools -> Error console ?
I don't think there's a need for a log - deleting messages marks them read first, in the view code (which I find highly annoying, actually), and the move undo code has no idea that this happened, and really no way of finding out. So it's a known issue, with no clear fix.
Ok I was just hopping thru the unconfirmed list, as long as its known. It sorta makes no diff to me, as I don't use TB in this fashion.
no problem, just didn't want folks to go looking for regression ranges or anything :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
The last log entry is almost 6 months ago. I'm not involved in the development of Thunderbird and I'm not a good C/C++ programmer, but this problem should be pretty easy so solve, because it should just be a matter of removing code. In TB2 deleting messages was just a shortcut of "move to Trash". In TB3 someone thought to do a good thing and added a "mark all read" routine before "move to Trash". Now someone (what about the person who added this code?) just has to remove the "mark all read" routine. It is very annoying to avoid using the del-key, but to move messages to the Trash folder, so that the unread flag does not get lost.
OK... Now this thread is current. It is REALLY ANNOYING not being able to see which messages in the trash bin were not opened. Part of my "routine" is being able to see the messages I haven't opened when checking before a permanent delete. Now I have to actually scan down through every message to ensure I am not permanently deleting something I wanted accidentally. I KNOW that if they are unread, they are unnecessary, so my time spent on email is dramatically increased. I hope that you guys will start following up on this bug. As a developer, I HAVE to believe that this is an easy fix. Find out what line is marking the message as read and remove it. You know when it happens - on a delete event. This cannot be rocket science. I LOVE Mozilla and its products, but jeez this should never have gotten past QA much less been an active bug for a year. Send me the code for the delete message event. I don't care what language it is. I think I can find it. Or maybe it is a system event I won't find, but I have a strong feeling that I will since it wasn't an issue in earlier versions. Peace, Eric
I believe it's the delete that's marking the message read, not the undo. And, unfortunately, it's marked read separately, in the front end, before the delete happens in the backend, so the undo action has no idea that the message was originally unread.
The quick fix for this in 3.1.2 is to comment out line 615 in messenger.jar:content/messenger/mail3PaneWindowCommands.js Can someone fix this please?
(In reply to comment #17) > Can someone fix this please? urk, I just hit this because of a sticky shift key - which resulted in select all instead of select thread. I haven't looked yet for the bug bienvenu mentions in comment 16 (I assume one exists). the net effect of this bug is dataloss.
Severity: normal → critical
Component: Mail Window Front End → Folder and Message Lists
Keywords: dataloss
OS: Mac OS X → All
QA Contact: front-end → folders-message-lists
comment 5 (3.0b2e) is odd, given that bug 211439 was fixed in 3.0b1. N.B. ... (In reply to David :Bienvenu from comment #10) > I don't think there's a need for a log - deleting messages marks them read > first, in the view code (which I find highly annoying, actually), and the > move undo code has no idea that this happened, and really no way of finding > out. So it's a known issue, with no clear fix. (In reply to David :Bienvenu from comment #16) > I believe it's the delete that's marking the message read, not the undo. undo still has a problem per the following test: - in folder X delete an unread message - in Trash folder, see the message is read - mark the message unread - go back to folder X, pick undo The message is in trash that was marked as UNread appears in folder X as read
The idea of Bug 274022 (for which dagger has an addon) - add option not to to mark mail as read when deleting - might help mitigate bug 211439.
If this is just a matter of making the 'mark to be deleted messages as read'-code dependent on a pref, I could look at this. But do we have UX agreement this is wanted as a pref in the Options dialog? If yes, where?
Assignee: nobody → acelists
Flags: needinfo?(bwinton)
Well, that's a different way to handle it. For this bug I was thinking more of adding code to mark messages as un-read when un-deleted. And no prefs. ;)
Flags: needinfo?(bwinton)
But I understood the code to mark them read before deletion was intentional. So how do we know which ones are to be marked unread at undeletion?
(In reply to Blake Winton (:bwinton) from comment #22) > Well, that's a different way to handle it. For this bug I was thinking more > of adding code to mark messages as un-read when un-deleted. And no prefs. > ;) An idea no doubt acceptable for some use cases. But I'm not sure what the average or majority examples would be. However, I've had 5-6 cases of mass accidental deletion, sometimes all messages in a folder. Not having unread status restored is flat out dataloss and not acceptable. Today's case: imap Inbox 1971 messages, 124 of which were marked unread because they still needed action. (and because I just remembered my laptop has this state, I can mark the ~124 messages unread) Perhaps various premise that led to bug 211439 should be reexamined. IMO it had a low bar for being accepted and did not examine possible impact to areas other than a one way operation of simply deleting a message.

Perhaps a good approach to this bug is to offer the user a preference as suggested by Aceman.

An IMAP account offers a user interface starting with "when I delete a message". adding a preference or two to that list would be a likely resolution. It would mean expanding POP to have such an option. But pop is sadly lacking a user interface for setting the special folder flag on a "deleted" folder, so perhaps both could be done together. set a folder (for POP) and a mark as read option for both.

You need to log in before you can comment on or make changes to this bug.