308063 - DEL key (esp. on focused selection of text) in unsent/saved draft message unexpectedly deletes the message. Irrecoverable data loss when expcting SHIFT+DEL to cut text to clipboard instead of permanent message deletion!

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Miklos Pal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Reading an unsent message, the text is displayed as read only, but an appearing
text selection may suggest to the user, that the text can be edited. If the user
presses the DEL key, the message will be deleted rather than the selected text
by Thunderbird. DEL key should have no function when the read only message text
window is active (both in frame and stand alone). The backspace key works fine,
it does nothing.
The message can be undeleted by UNDO, but only one message, because UNDO has a
single level only.

Reproducible: Always

Steps to Reproduce:
1. Write a message
2. Choose "File/Send later"
3. Click to th emessage in Local Folders/Unsent
4. Click the message frame, select some text, or open the message and select
some text
5. press the DEL key

Actual Results:  
The message has been deleted

Expected Results:  
Nothing. The message should be deleted by the DEL key only if the message list
window (frame) is active.

Comment 1

[Brian Hershman]

I have found exactly the same thing when reading old messages in any folder, both when the message is read in its own window and when it is shown in the message pane. Sometimes UNDO will restore it, at other times it cannot be UNDOne but can be found in the Trash folder, occasionally it disappears completely.

What seems to happen is that even though the cursor may appear to be in the message itself, it is effectively on the corresponding item in the index-listing. So DEL applies to the index-listing, not to the highlighted text in the message.

To avoid this, the bug that highlights text in a READ-ONLY window or pane should be corrected.

Comment 2

[Wayne Mery (:wsmwk)]

the may be an example of ...
 a) something that happens so infrequently, 
 b) it's recoverable with undo (no way to change that for local folders, right?)
 c) make the mistake once and you won't (or shouldn't) do it again 
... such that it's not worth changing.

WONTFIX IMO
dupe of bug 330576

Comment 3

[Brian Hershman]

Let's not be so snotty-nosed. My non-geekish wife came across this bug. Luckily for her, my 40 years' experience in IT enabled me to check it out and report the conclusion that I stated in comment #1.

As I understand it, Thunderbird is used by many more non-professionals than professionals. While you and I may be smart and experienced enough to have worked out what is going wrong and understand enough not to do it again, the majority of users are not in that fortunate position - when they think they are doing a little text editing and the whole message disappears, sometimes without trace, they panic! Without professional help, they cannot learn what they have done and not to do it again.

So fix this bug for them, please.

Comment 4

[Brian Hershman]

This bug still exists in TB 12.0!! I have just tested it again, over 4 years after I raised it and 7 years since it was originally raised.

So, regardless of its declared status, it has not been resolved. My comments of 2007-09-13 still apply.

If I had to pay for TB, I would be furious and would consider (but not for long) suing Mozilla.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Brian Hershman from comment #4)
> This bug still exists in TB 12.0!! I have just tested it again, over 4 years
> after I raised it and 7 years since it was originally raised.
> So, regardless of its declared status, it has not been resolved. My comments
> of 2007-09-13 still apply.

-> Reopening.

This is not exactly a duplicate of clumsy bug 330576 (which is completely unaware of the current message deletion design and thus rejects it without reason or plausible scenarios).

The following two aspects of this bug deserve second thoughts:

A) The scenario of this bug looks at Saved Drafts/Unsent messages (viewed with message reader).

Trying to edit the text of saved drafts / unsent messages is a much more plausible scenario than just pressing DEL randomly on a received message, so this is a legitimate case of ux-error-prevention.
Worse, if you happen to use Caret browsing (F7), you'll even have a fully functional blinking caret in the message text which makes it even easier to erroneously assume you are already editing your draft message - again, a clear case for ux-error-prevention.

B) The scenario of this bug explicitly refers to pressing DEL *on selected text* (again different from bug 330576).

Iow, user explicitly selects some text before pressing DEL, erroneously assuming to edit the selected and focused text. Again, apart from the small error of forgetting to click the "Edit..." button to return the draft into editing mode, the general intention of deleting selected text from a saved draft/unsent msg is very plausible.

So essentially this is a violation of *focus* (ux-consistency). 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-consistency and ux-error-prevention.


In the same line: Seamonkey Bug 302828 (currently NEW): Erroneously deleted mail instead of deleting just the selected part (ReadMode)
That bug mentions another scenario where with many windows (or tabs) open, user simply gets confused to wrongly assume the currrent window (or tab) of a received msg is in reply mode.

Similarly, there's Bug 374853 - *Shift*+DEL in msg (pre-)view should always cut/copy selected text and not delete message (legacy key bindings). While the proposed behaviour there needs reconsideration, the scenario still applies:
To this day, you can cut selected text to clipboard in Windows and popular office applications like MS Word using Shift+DEL (in Windows Explorer, press F2 to rename a file, then Shift+DEL on selected text -> cut to clipboard; in Word, highlight text and press Shift+DEL, then Shift+Insert elsewhere).
Though perhaps a less frequent scenario, again this adds to the need for ux-error-prevention because msgs accidentally deleted with Shift+DEL (in good faith and relying on focus respect) cannot be recovered by normal users.

Finally, will it really hurt anyone if [Shift]+DEL do nothing in those particular cases where user has explicitly selected some text from the msg body?
I still think selecting text and then wanting to delete that very message is not a very frequent scenario, and it's easy enough to get rid of the selection by just hitting a cursor key or clicking anywhere outside the selection. Much easier than recovering deleted message(s) from trash, or facing the message dataloss of erroneous Shift+DEL on selected text.

Comment 8

[:aceman]

We can distinguish whether the focus is in the message list or in the message reader pane. We could disable Del when in the message pane. However, that doesn't seem enough. It looks like we want to enable Del (yeah, bug 330576 doesn't) when viewing a message in a new tab.
So what is the exact algorithm we decide whether to delete whole message or not? Is the existence of selected text the deciding point?

Comment 9

[Jim Porter (:squib)]

Given that we can simply undo the deletion, is this really necessary? (Granted, I think we can't undo if you delete from trash, but we could add that to the list of cases where we prompt the user before deletion.) It's certainly reasonable for a person to, say, copy some text from an email and then delete it.

Comment 10

[Wayne Mery (:wsmwk)]

First, to be really picky if one is to keep this bug a special case of bug 330576 as comment 5 suggests, then bug 701470 and bug 1014938 are dups of bug 330576.  But I'm not sure the distinction made in comment 5 is worth the special casing this bug.

Having said that ...

(In reply to Jim Porter (:squib) from comment #9)
> Given that we can simply undo the deletion, is this really necessary?
> (Granted, I think we can't undo if you delete from trash, but we could add
> that to the list of cases where we prompt the user before deletion.) It's
> certainly reasonable for a person to, say, copy some text from an email and
> then delete it.

Also, users highlight text and click reply. I do this frequently. Well established behavior, but I'm not sure how common it is because it's not a discoverable use case. 

One can also highlight text in the message header and not in the message body, then hit delete.  

There's no question we can change the behavior. The question is should it?  In no particular order (but numbered to facilitate discussion) here are some thoughts:

#1 it makes zero sense to have text selected in a readonly view and expect the text to be deleted
#2 is it really a big (or even modest) problem, in the sense that this affects many users?  (I suggest by the relative lack of bug comments, dups and support reports that it does not, by any stretch of the imagination)
#3 should/must proper focus protocol be observed, regardless of any other issues? - comment 5 above, bug 302828 comment 5  (I sympathize with this POV but...)
#4 we have precedent in bug 330576. And along those lines ...
#5 we have explicitly established "improper" focus behavior to explicitly facilitate workflow of deleting  messages - i.e. despite message in thread pane not being focused. It is not an accident, nor mere developer oddity that Thunderbird behaves in this manner.  Indeed, it is not necessary to have any text selected at all - although that seems to be the most common usecase where users "accidentally" delete a message.
#6 "Fixing" this bug will force users who want to delete a message and have selected text to either explicitly refocus the message in the thread pane, deselect the text, or suffer whatever UI is imposed by this bug.

So which item(s) carry the most weight?

My thought is to continue current behavior unless there is a *very* compelling rationale to change it. With emphasis on *very*.  

Is there middle ground where everyone wins?

Comment 12

[Thomas D. (:thomas8)]

I think we haven't looked at possible solutions for this yet.
The simplest solution imo is this:

IF message currently viewed in message reader is a DRAFT
AND
IF some draft *text is selected*
AND
IF user presses DEL in that very situation
THEN show a confirmation dialogue like

"Are you sure you want to delete this draft message?" [Delete draft][Cancel]

(In reply to Wayne Mery (:wsmwk) from comment #10)
> First, to be really picky if one is to keep this bug a special case of bug
> 330576 as comment 5 suggests, then bug 701470 and bug 1014938 are dups of
> bug 330576.  But I'm not sure the distinction made in comment 5 is worth the
> special casing this bug.
> 
> Having said that ...
> 
> (In reply to Jim Porter (:squib) from comment #9)
> > Given that we can simply undo the deletion, is this really necessary?

Undoing deletion is NOT a simple scenario for many normal users.

> > (Granted, I think we can't undo if you delete from trash, but we could add
> > that to the list of cases where we prompt the user before deletion.) It's
> > certainly reasonable for a person to, say, copy some text from an email and
> > then delete it.
> 
> Also, users highlight text and click reply. I do this frequently. Well
> established behavior, but I'm not sure how common it is because it's not a
> discoverable use case.

Wayne, this bug is explicitly reported against DRAFTS. I don't think users will ever reply to selected text of their own *draft* message. So I think the main critical argument cited against this bug does not apply, so there's virtually no disadvantage to the power user scenario of DEL to delete messages regardless of focus. So this specific bug should just be fixed. Another point in favor of this bug: You and I might be experienced enough to have that muscle memory that editing a draft message always requires that extra click on that little "Edit..." button in the corner of message reader. I imagine things might be different for new users, and any types of users can easily have an unfocused moment where they forget they are not yet in editing mode.

> One can also highlight text in the message header and not in the message
> body, then hit delete.

Again, unlikely / not applicable for drafts. I don't think many users will create a draft, then copy some stuff from header, then delete the draft - what was the point of creating the draft then?

> There's no question we can change the behavior. The question is should it? 
> In no particular order (but numbered to facilitate discussion) here are some
> thoughts:
> 
> #1 it makes zero sense to have text selected in a readonly view and expect
> the text to be deleted

For received messages, probably yes. But alas, again, this is about DRAFTS: so as described in detail in this bug and recent duplicate bug 1061026, it's quite possible especially for less experienced users of TB to believe (in that non-attentive moment) they are already in editing mode, simply because they are looking at their own text in the draft. The concept of having to click the "Edit..." button before editing the draft imo is not something which is very natural/intuitive/discoverable by itself.

> #2 is it really a big (or even modest) problem, in the sense that this
> affects many users?  (I suggest by the relative lack of bug comments, dups
> and support reports that it does not, by any stretch of the imagination)

We don't know how often this occurs, but when it does, it's really nasty and datalossy.
More importantly, as explained above in this comment, I don't think the competing power user behaviour benefits from keeping status quo.

> #3 should/must proper focus protocol be observed, regardless of any other
> issues? - comment 5 above, bug 302828 comment 5  (I sympathize with this POV
> but...)

I'm known to sympathize and campaign for this POV ;)

> #4 we have precedent in bug 330576. And along those lines ...

As opposed to this very specific bug here, Bug 330576 doesn't have a plausible scenario and just calls for the blanket removal of the ux-efficient power user behaviour.

> #5 we have explicitly established "improper" focus behavior to explicitly
> facilitate workflow of deleting  messages - i.e. despite message in thread
> pane not being focused. It is not an accident, nor mere developer oddity
> that Thunderbird behaves in this manner. 

Agreed, but not applicable to this bug as the power user workflow is not affected (see above).

> Indeed, it is not necessary to
> have any text selected at all - although that seems to be the most common
> usecase where users "accidentally" delete a message.

Yes. We're only talking about "selected text in draft" scenario here.

> #6 "Fixing" this bug will force users who want to delete a message and have
> selected text to either explicitly refocus the message in the thread pane,
> deselect the text, or suffer whatever UI is imposed by this bug.

Ditto, not applicable to this particular scenario of selected text in DRAFT messages, which is the only scenario this bug seeks to fix (e.g. by presenting a confirmation before deleting, so even the unlikely scenario of draft messsage deletion while text selected would still be possible with just one or two extra keypresses).

> So which item(s) carry the most weight?

In view of the above, imo ux-error-prevention against datalossy behaviour for drafts clearly wins given this the ux-efficient power-user scenario does not even apply to the scenario of this bug (and we're not removing the power user feature even for the very unlikely scenario intending to delete my onw *drafts* with *selected text*).

> My thought is to continue current behavior unless there is a *very*
> compelling rationale to change it. With emphasis on *very*.  
> 
> Is there middle ground where everyone wins?

Per above, fortunately yes. Just fix this bug, problem solved for everyone without any noticeable losses for power users. If required (I think not), we can still design the confirmation dialog in ways that prefers the power user scenario (default button = [Delete draft]).

Comment 13

[Thomas D. (:thomas8)]

Comment 12 argues for the minimal fix of the worst parts of this bug, smallest common denominator.

Notwithstanding, imo we should err in favor of ux-error-prevention for another case currently not covered by this bug:

- IF caret browsing is on (visible blinking cursor in message reader), and IF current msg is DRAFT, we should also show the "Delete draft?" confirmation dialogue even when there's no text selection. For the same reasons as in comment 12. Generally, I think clicking around in drafts and then deleting them is not a frequent scenario.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #13)
> Comment 12 argues for the minimal fix of the worst parts of this bug,
> smallest common denominator.
> 
> Notwithstanding, imo we should err in favor of ux-error-prevention for
> another case currently not covered by this bug:
> 
> - IF caret browsing is on (visible blinking cursor in message reader), and
> IF current msg is DRAFT, we should also show the "Delete draft?"
> confirmation dialogue even when there's no text selection. For the same
> reasons as in comment 12. Generally, I think clicking around in drafts and
> then deleting them is not a frequent scenario.

Even without caret browsing, if user has placed focus in message reader showing DRAFT (believing to have placed editing cursor), and then presses DEL, confirmation dialog "Delete draft?" is required for ux-error-prevention, which clearly wins over ux-efficiency (just press Enter to delete draft anyway).
That's also ux-consistent with the fact that we *always* ask "Save changes?" when user closes draft. I don't see why a saved(!) draft would deserve so much less protection against accidental deletion than the live composition (pre-draft).
Composed text is unique data which is not easy to recreate, so it should be protected against accidental dataloss. Retrieving from trash isn't discoverable so not an appropriate alternative, and might not be possible after trash has been deleted or not possible at all for IMAP scenarios.

Also note that out of 4 duplicates (incl 1 SeaMonkey), 3 are recent.

Comment 15

[Josiah Bruner [:jsbruner]]

Personally I'm not a fan that we can use Delete at all (even outside of drafts). Why are we deleting something when the user never specifically selected something to delete? This is especially evident on OS X, where backspace *is* the delete key (and is located right by power and volume up).

That said, if we are going to allow people to delete simply with the DEL key, then let's just show the confirmation dialog everywhere (not specifically drafts). Of course I would rather have the shortcut changed entirely, i.e. CMD+DEL, but it's a little late for that now.

Comment 16

[Magnus Melin [:mkmelin]]

Processing mails by hitting Delete is a primary workflow for me, and probably for many many people. You implicitely select a message when you read it.

Comment 17

[Wayne Mery (:wsmwk)]

Attachment: tb undo ignore thread.png

(In reply to Magnus Melin from comment #16)
> Processing mails by hitting Delete is a primary workflow for me, and
> probably for many many people. You implicitely select a message when you read it.

Yes

From a workflow perspective this bug is not different from wontfix bug 370770 comment 3.  


(In reply to Thomas D. (currently busy elsewhere) from comment #12)
> ...
> > (In reply to Jim Porter (:squib) from comment #9)
> > > Given that we can simply undo the deletion, is this really necessary?
> 
> Undoing deletion is NOT a simple scenario for many normal users.

The issue here is visibility.  Undo doesn't have a toolbar button (bug 475256), and isn't in the appmenu (bug needed?), - it exists only in the menu bar which is hidden by default.  

Perhaps we should do something in status bar like what is done for ignore thread (see attached), or what gmail does by offering an undo non-blocking popup.

Comment 19

[chrizilla]

­

Comment 21

[chrizilla]

Adding as duplicate: bug 374853, which describes the same user mistake but compounded by the use of SHIFT+DEL instead of DEL only, thus resulting in permanent data loss!

Thus carrying over severity=critical from closed duplicate bug 374853 based on:
(Wayne Mery (:wsmwk) in comment #4 of bug 374853)

sev=critical because of potential dataloss for messages in local folders

Comment 22

[Wayne Mery (:wsmwk)]

Thanks for triaging.
Dataloss alone (and in the instance an edge case for sure) does not merit S1 severity, which is release blocker.
And given the age of this issue we need to let the team determine priority. (which they would anyway)

Comment 23

[chrizilla]

Thank you for the correction.

• I know priority is reserved to those in charge. I did not want to touch it, but it was impossible to avoid, since it is auto-hardlocked to P1for S1. (I pondered mentioning this in the comment, but passed on it, since I expected everyone to know anyway.)
• Severity: I am sorry, I didn't know about release-blocking, that's not mentioned in the docs. Sorry for any inconvenience. I was closing bug 374853 as a duplicate of this and saw a need for carrying over its higher severity to here for 3 reasons:
  1. Because it was you, who upgraded severity from major to critical in comment #4 of bug 374853. I wanted to keep/honour your choice for I was sure you did so for good reason. The critical value of the old severity scale corresponds to S1now, so I selected that.
  2. This bug here doesn't immediately result in data loss, since the DEL key merely sends the message to the trashcan from where it can be recovered. This is all that was discussed in this bug as well as in all duplicate bugs. Bug 374853 describes the same scenario except that SHIFT+DEL was pressed, which did cause immediate and irrecoverable data loss! This danger was not discussed and not taken into account in this bug here and I did not want this to slip out of sight as a consequence of dupe-closing bug 374853, so I thought the best way was to carry over bug 374853's severity and spotlighting the much greater danger of its meaner brother bug.
  3. Data loss is mentioned as a deciding factor for S1 in the user guide.

Regarding this being an "edge case" as you say ... sure, at first glance the risk of falling victim to this trap seems pretty remote. That's what I thought, too. But after having read all comments of all the duplicate bug reports and having seen how often this is mentioned in user stories, I think we must acknowledge that this is more than just a black swan event but a real thing. The problem appears to be more common than expected by computer experts who would themselves never mistake the current state of the program (ux-mode-error: edit mode vs. view mode ... especially if a draft message is concerned). This is truly happening and a real source of data loss – even irrecoverable data loss in the case of SHIFT+DEL. I was completely oblivious that this key combination can be used for cut/paste operations. I just tried it, it's true. That's a very unfortunate concurrence. Fortunately the risk has been somewhat mitigated by changing the default of mail.warn_on_shift_delete to true.

There may be more catastrophic bugs, but after having read the numerous and vivid reports, I would caution against underestimating this problem.

Comment 24

[chrizilla]

Adding the special case of SHIFT+DEL to the bug title.

Comment 25

[Wayne Mery (:wsmwk)]

It may not be obvious, but:

• old scale Blocker corresponds to S1
• old scale Critical corresponds to S2
• historically most Thunderbird dataloss bugs are designated Critical, therefore not S1 - as seen in this chart only 1% of Thunderbird dataloss bugs are S1
• It is unfortunate that in the current guide dataloss is only mentioned in the S1 category. That description is an oversimplification. Because it is still the case that most dataloss bugs are in fact S2 and do no merit blocking a release, as illustrated in this table of FIrefox dataloss bug reports of the last 10 years and table of open Thunderbird dataloss bug reports - there are zero S1 bug reports.

The S1 designation really should be summed up as "we won't ship with this bug" in it, which is somewhat subjective. And so applying S1 is more nuanced than the literal interpretation of the currently worded criteria, i.e. a bug which is dataloss must have some additional significant factor happening for it to elevate to S1.