895140 - Implement pref for optional confirmation dialogue for Delete messages command (required for disability access)

Status: NEW

(Thunderbird :: Disability Access, enhancement)

Description

[Neil Parks]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 IceDragon/22.0.0.1 (Beta/Release)
Build ID: 20130711101616

Steps to reproduce:

I have Parkinson's Disease.  This causes an occasional tremor in my hands.  As a result, sometimes when I intend to press a key once, I inadvertently press it twice.

This creates a problem when I try to delete a message.  There are times when I wind up deleting two messages.  Then I have no choice but to dive into the Trash folder, and try to get the wrongly deleted message back where it belongs.

I have two suggestions for fixing this problem.  

One idea would be to create a "confirm delete" option.  This option could be toggled on or off in the Tools/Options or the editable preferences.  When it is toggled off (the default), TBird behaves as it does now, deleting the current message immediately.  When it is toggled on, Tbird will pop up an are-you-sure window.  If the user clicks "yes" or presses Y or Enter, the msg is deleted.  If the user clicks 'No" or presses N or Escape, the msg is not deleted.

The other idea is a "recall" function.  If the user calls that function (perhaps from the Message menu?), the most recently deleted message is moved from Trash, either to the currently open folder or to the one from which it was originally deleted.  

(In most cases they would be the same.  Relative ease of programming the function would determine which you would use.  I imagine it would be very similar to the Uppercase J function which moves a msg from the spam folder back to where it came from.)

Comment 1

[Wayne Mery (:wsmwk)]

see alt + Edit + Undo
aka ctrl+Z  :)

Even with undo, does this problem happens frequently enough or in high enough "multiples of keystrokes" (i.e. greater than 2 deletes) that the solution you suggest be better than having to frequent resort to undo?

Comment 2

[:aceman]

I would support the adding of some confirmation dialogs like this for people with disabilities or elderly people for which an admin wants to setup TB and preventively lock it down a bit. I already observe another request for locking the message columns so that unintended clicks on column headers do not resort msgs.

The individual features would have separate prefs, but we could have a single checkbox in the Preferences dialog toggling them all. Bwinton, would that be something useful? We could have a meta bug linking which features are enabled by that option.

For the bug here, notice we already have a warning dialog on delete at http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgDBView.cpp#3062, which seems to trigger for some cases (e.g. news, or shift-delete). So adding a pref for general msg delete should be especially cheap.

Comment 3

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #2)

+1 on this request, agree with :aceman's comment, with or without the general switch for "child-proof" lock of some UI settings, the details of which we'd have to figure out to see if it works.

Comment 4

[Thomas D. (:thomas8)]

Notwithstanding our reasonable comfortable default behaviour (delete without confirmation), this is also recommends itself at least as an option to behave ux-consistent with deleting files in OS file manager, where confirmation is usually asked before sending stuff to trash.

Comment 5

[Magnus Melin [:mkmelin]]

I don't thinki'm so keen on this. Actually using thunderbird with a confirmation dialog for each delete would be really clumsy for anyone, and like Wayne mentioned, undo is easy.

Comment 6

[Neil Parks]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> see alt + Edit + Undo
> aka ctrl+Z  :)
> 
> Even with undo, does this problem happens frequently enough or in high
> enough "multiples of keystrokes" (i.e. greater than 2 deletes) that the
> solution you suggest be better than having to frequent resort to undo?

I had absolutely no idea till now that Ctrl-Z (undo) could reverse the deletion.  

I just tried it, and it is exactly what I was looking for.  Thanks.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Neil Parks from comment #6)
> I had absolutely no idea till now that Ctrl-Z (undo) could reverse the
> deletion.  

One thing I very much admire about google gmail web, is that they offer an unobtrusive link and text reminding you that a delete was done and that you can undo it.  Perhaps we should offer something like that, or a one time dialog when user does their first delete of a message.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to Neil Parks from comment #6)
> > I had absolutely no idea till now that Ctrl-Z (undo) could reverse the
> > deletion.  
> 
> One thing I very much admire about google gmail web, is that they offer an
> unobtrusive link and text reminding you that a delete was done and that you
> can undo it.  Perhaps we should offer something like that,

+1, notification bar with undo link sounds even better than optional confirmation dialogue

> or a one time
> dialog when user does their first delete of a message.

I'd rather avoid that

Comment 9

[Jim Porter (:squib)]

Just so everyone knows, it's actually pretty trivial to add an off-by-default prompt when you delete a message. We already prompt during shift-delete and deletion of a news message, since those aren't undoable. Those cases can also be hidden via a pref, so we could do the same thing here, except the default pref value would be inverted.

That said, I don't really think this is that valuable, since we have undo.

Comment 10

[Neil Parks]

The ctrl-z undo solved the problem that caused me to open this bug report.  

And T-bird does give a warning now if the delete is not reversible.

Therefore I suggest closing this.

Comment 11

[Wayne Mery (:wsmwk)]

Thanks for these comments.

I don't believe the average user has an expection that delete behavior in an email client mirrors the OS file system.