302828 - Erroneously deleted mail instead of deleting just the selected part (ReadMode)

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Hermann Schwab]

I wanted to reply to a mail, had a lot of windows open, had looked into the
header, and somehow had a full sized mail window, thinking I was replying, I
selected part of the mail, and pressed the Delete key.
I wasn't in Reply-Mode, I was simply reading the message.
Instead of deleting the selected part, or giving an error message, the full mail
was deleted, also from the server, as that are my settings. Maybe I pressed Del
twice, a second mail was also gone.

This shouldn´t happen. If only part of a mail is selected, the full mail
shouldn't be deleted, or only after confirmation.

Comment 1

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050729 SeaMonkey/1.0a

After sending me some testmails and playing around, I found I can undelete the
message, as it is still in the Trash folder. Ctrl-Z will do, or from the Edit
menu 'Undo ...'
Deleting:
If I try to delete via Right-Click, the context menu clearly offers: Delete Message.
The 'Del'-key however deletes the whole Message without warning, even if part of
it is only selected.
Imho it is ok to delete a message in Read Mode using a single keypress, without
confirmation, but if part of a mail is selected, this means 'delete only the
selected part'. As this doesn´t make sense in Read Mode, nothing should happen,
or a warning, but never overriding the selection and deleting all of it.

I'm not used to deleting mails in my mozilla mail accounts, my spam is going to
gmail and another webmailer, so no chance to train the mozilla spam filters.

Comment 2

[Claude Schnéegans]

I completely agree with you. In this case, the delete key should just make some error sound, period.

Comment 3

[Thomas D. (:thomas8)]

+1. The main reason is: violation of focus (a popular passtime with some developers). With focus explicitly on a small thing (selected text), we are violating natural UI expectations when deleting the big thing (containing message). Interestingly, some similar bugs have been fixed, after an endless struggle to convince developers (hence we no longer delete whole messages when user presses Del on a selected and focused attachment, bug 315144). This is exactly the same problem, and clearly an instance of ux-error-prevention.

Worse, if you happen to use Caret browsing (F7), you'll even have a fully functional blinking caret which makes it even easier to erroneously assume you are already editing the message - again, a clear case for ux-error-prevention.
And trying to edit a message from message viewer might be a pretty plausible scenario when it's a saved draft (or unsent message) that you are viewing.