374853 - Shift+DEL on selected and focused text in message reader should not delete message permanently (ux-error-prevention: legacy and current key bindings for "Cut" to clipboard)

Status: RESOLVED DUPLICATE of bug 308063

(Thunderbird :: Message Reader UI, defect)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Version 1.5.0.10 (20070221)

In several spots where text selection is possible, TB 1.5 respects legacy keybinding <shift+del> for cut to clipboard, or (as a courtesy), if cutting is not possible, copy to clipboard.

Examples:
- in composer, <shift+del> will cut selected text (OK)
- in msg header pane (msg preview or standalone msg win), <shift+del> will copy selected text (like the first name of sender, or some words from subject) (OK)
However, this legacy behaviour is inconsistent and therefore unpredictable:

In msg preview or standalone msg win, even when part of the msg text has been explicitly selected by the user, <shift+del> deletes the whole msg instead of intelligently respecting legacy key bindings: <shift>+<del> should just copy the selected part of the message text.

There are a range of bugs like 352793 or 315144 that request <shift+del> to behave more standards-conform, i. e. to respect the current focus/selection rather than always expunging a message regardless of the circumstances. I do see the advantage of enabling dirty deleting of a msg from inside the msg text, as it adds a lot of comfort to systematic check & delete of mails. BUT IMO this somewhat extraordinary/unexpected behaviour should be limited to exactly those two possibilities where there is no doubt that the current focus is on the msg as a whole:
a) msg is selected and focussed in msg list
b) msg is selected as focus is on msg content and there is no text selection
Any other cases (like bugs 315144, 352793)should respect the current focus/selection:

Whenever text has been selected, <shift+del> should cut to clipboard.
Where cutting is not possible (in msg preview), <shift+del> should /copy/ selected text(courtesy; intelligent legacy key binding interpretation)
Whenever focus is on some kind of object, that object should be deleted/expunged.

This approach should be consistent throughout the UI.

Just my 2 cents...

Reproducible: Always

Steps to Reproduce:
1. in msg preview / standalone win, select some text
2. press <shift+del> without thinking and expect it to cut (or copy) like in very old windows days and still possible in many apps today including TB
3.
Actual Results:  
Message will be permanently deleted without warning.

Expected Results:  
Selected msg text should always be cut/copied (where appplicable)
msg deletion should only work if either msg has focus in msg list, or msg (pre-)view has focus, but no text selection!

Comment 1

[Thomas D. (:thomas8)]

I still hold the view that after the user has deliberately highlighted (selected) some partial text of the message body of an inbox msg, pressing legacy cut command <shift>+<del> should not delete the msg for good, but rather copy selected text.

This bug is related to a number of other bugs around shift+del permanent mail deletion keyboard shortcut. IMO, shift+del behaviour should be unambiguous and predictable at all times by following generally acknowledged user experience patterns, plain & simple:

<Shift>+<Del> should only delete the email if there is no doubt at all that the user actually intends to do so. This will normally be the case if
a) msg is selected and focussed in msg list (tb main win)
b) msg can be considered selected as focus is on msg content and there is no other text selection or focus set (to cater for shift+del comfort fans)

Any other cases of shift+del (like bug 315144, or bug 352793) should respect the current focus/selection as can be expected from any standards-conform application.

Comment 2

[David Ascher (:davida)]

not a blocker

Comment 3

[Thomas D. (:thomas8)]

It would be nice to have this bug confirmed anyway.
When user deliberately selects (highlights) some text in a given message, I think it is very unlikely that the intention of using shift+del thereafter is to delete the message. Do YOU bother highlighting text in an email you are about to delete?

Comment 4

[Wayne Mery (:wsmwk)]

this isn't confirmed, because it's not clear where this is headed, in part because there are (relatively unknown) legacy and competing behaviors, and users can avoid this by modifying their usage behavior. but let's get more perspective with some cc:

related bugs:
bug 326869  Thunderbird: Shift+Delete keystroke poorly documented 
bug 308690  No confirmation message when when force deleting messages with SHIFT+DEL 

bug 315144 not really related/has different solution
sev=critical because of potential dataloss for messages in local folders (but one would hope a user would learn "don't do that" after the first occurrence)

Comment 5

[Magnus Melin [:mkmelin]]

(In reply to comment #3)
> to delete the message. Do YOU bother highlighting text in an email you are
> about to delete?

Actually, yes. Fairly often I'd copy some text from a mail (e.g. to search for what it is, copy bug numbers from bug mails etc.) and then get rid of the mail.

Comment 6

[Thomas D. (:thomas8)]

Thanks for the quick feedback, especially @Magnus for providing the use case against the suggested fix of this bug. Good point. So we're now in the trade-off zone. Admittedly, there's a weak point in this bug: even legacy shift+del means "cut" (and not "copy"), and cut naturally isn't possible in received mail, so I'm really asking for a legacy courtesy. And if cut isn't possible in that specific situation, even the otherwise rock-solid "focus respect" argument starts to crumble... ;-) (I think the scenario I had in mind was that user might be negligent when it comes to differentiating between compose and read mode. So someone with legacy reflexes might accidentally try to cut from a message in message READER...)

In other words, I wouldn't mind to withdraw this one as soon as there is some way of preventing accidental dataloss due to shift+del, which is a real danger as pointed out by Wayne's setting sev=critical in comment #4.

If this bug gets dropped, for reasons of consistency I suggest that <shift+del> on selected text in message reader's header pane should no longer copy text, but just do nothing. Using <shift+del> to COPY is a flawed concept from the start, my mistake. I think we agree that it's all right to keep legacy <shift+del> for CUT where you can actually cut things out, like in message compose.

Comment 7

[Thomas D. (:thomas8)]

As a midway solution, consider making <shift+del> do NOTHING when text is selected in message reader. However, that's one extra click or one extra keystroke to get rid of selection before you can use <shift+del> to delete the msg.

The following bug might be added to Wayne's overview "for more perspective" as per comment #4:
Bug 132121 -  Can't undo shift delete of local messages

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

The compromise offers too much hidden behaviour so I can't accept it.  It will add the possibility of confusing both sets of users who don't want this and those who do want this behaviour.

I'd recommend the correct route is to make the behaviour as you actually want it through an extension.  I am not turning you away, make no mistake.  I'm helping a number of people get extensions together for just this kind of thing.  See bug 391272 comment #41 where an extension is already underway ( http://twitter.com/clarkbw/status/1777479820 )  The extension will likely be fairly simple to code and then I can help you get it into https://add-ons.mozilla.com/ so others can have this behaviour as well.

Comment 9

[Wayne Mery (:wsmwk)]

mentioned also in http://www.spreadthunderbird.com/node/245

shift-delete controller extension may do part of what is needed https://addons.mozilla.org/en-US/thunderbird/addon/1550

I think we are in bug 330576 territory. And I don't find any unduped bugs, IOW, I'm not sure this bug should stay open based on 3-4 reports in ~4 years time. I suggest the be closed duplicate

Comment 10

[Thomas D. (:thomas8)]

Comment 0 needs reconsideration (one of my first bugs...)
IMO the main problem remains a valid issue.
I'll sort out relations with similar bugs.

Comment 11

[chrizilla]

(In reply to Wayne Mery (:wsmwk) from comment #9)

I think we are in bug 330576 territory. And I don't find any unduped bugs, IOW, I'm not sure this bug should stay open based on 3-4 reports in ~4 years time. I suggest the be closed duplicate

From my readings, the problem described here is identical with bug 308063 except that SHIFT+DEL is pressed instead of DEL, which of course gravely worsens the outcome (permanent data loss!).

Since you also suggested this bug to me marked as duplicate 15 years ago already, I will do so. However, to make sure that the aggravation of the problem by pressing SHIFT+DEL is taken into account, I have left a note in the user story and in comment #19 of bug 308063.