Closed Bug 526541 Opened 15 years ago Closed 13 years ago

Please add a "confirm on delete" option for address book entries...

Categories

(Thunderbird :: Address Book, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 6.0

People

(Reporter: fred, Assigned: mconley)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [GS])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Build Identifier: version 2.0.0.23 (20090812)

Please add a "confirm on delete" option for address book entries

I often accidentally delete entries via the following scenario:
- Open Address Book
- Start typing a name to autoscroll to that person
- Hit Delete key on Mac keyboard to delete the last letter I typed 
  because it was a typo
- Oops!  Whatever address book entry I had autoscrolled to silently 
  vanishes.

This is very easy to do accidentally since so many apps these days
do incremental searches like this and allow Delete or Backspace to 
delete the last search char typed.  My fingers are well trained to
make this mistake.

Most of the time that it happens, the user is likely to not even 
notice that an address book entry has been deleted.  If he notices
later, he will have no ideas why, and will falsely blame a bug in 
Thunderbird that it mysteriously loses addresses.

Even if the user does notice immediately, he may not easily be able
to determine which entry was deleted, in order to add that entry back.

Even if he knows which entry was deleted, he may not know the e-mail
address or other info that was stored for that entry, or which mailing
lists that entry was on.

A LOT of data can be lost with a simple keystroke.  Please add a confirm
option or change Delete to mean delete the last char I typed during the 
incremental search.

Thanks,
--Fred Stluka



Reproducible: Always

Steps to Reproduce:
1. Open Address Book
2. Start typing a name to autoscroll to that person
3. Hit Delete key on Mac keyboard to delete the last letter I typed 
   because it was a typo

Actual Results:  
Whatever address book entry I had autoscrolled to silently vanishes.


Expected Results:  
The last letter I typed should have been deleted from the search criteria.
confirming every single delete would be tedious - maybe bug 94407 ?
I don't think confirming every delete from the address book would 
be tedious at all.  How often do you intentionally delete one?  
Almost never.  Also, if you selected multiple, a single confirm 
dialog would be fine.

Bug 94407 suggests having an undo/redo for address cards.
That is a related, but not identical issue.  However, the comments
added to that issue DO cover the pros and cons of the confirm option 
pretty well, emphasizing accurately how important it is to have both.

I'm surprised that bug 94407 is a couple of years old and not yet 
addressed.  Thunderbird is SUCH a GREAT product!  But this is a 
pretty important issue.  I lost lots of addresses before I figured
out what was happening.  Fortunately, I am just anal enough to have
automated a backup solution that dumps the address book in textual 
form and compares it with the last known good version before doing
a backup.  So, I think I've always caught the problem before it was 
too late.

Please get to this soon.   I'm moving lots of clients, friends, and 
family to Thunderbird, and don't want them losing their contacts.

Thanks!
--Fred
Fred, can you file a separate bug for Mac OS X to temporarily disable Thunderbird's keyboard shortcut for deleting entries after a quick search was performed? It seems like this bug is about adding (an option for) a confirmation dialog, which I support; if OS X Thunderbird behavior was to ignore the Delete key for a short time after characters were typed to select entries, this bug would partly go away, but it's still good to have them separate.

This bug is an enhancement for all platforms.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → 3.0
(In reply to comment #5)
> Fred, can you file a separate bug for Mac OS X to temporarily disable
> Thunderbird's keyboard shortcut for deleting entries after a quick search was
> performed? It seems like this bug is about adding (an option for) a
> confirmation dialog, which I support; if OS X Thunderbird behavior was to
> ignore the Delete key for a short time after characters were typed to select
> entries, this bug would partly go away, but it's still good to have them
> separate.
> 
> This bug is an enhancement for all platforms.

Nathan,

I'm not sure I like the idea of ignoring keystrokes for a short time.
Sounds too indeterminate.  Leads to race conditions, where the delete 
key does different things depending on how fast the user types.  Too
hard to predict, and thus will be perceived as a bug, especially if 
one of the things is to delete an entire address book entry.

Besides, I'd rather see the delete key delete the most recent keystroke 
of the auto-search string, as I originally expected it to do.  That's 
a better match to other apps with auto-search of lists.  I don't have
a Windows version of Thunderbird handy.  What does the Windows version 
do with the Backspace key, which is in the same location on the keyboard
as the Mac Delete key?

--Fred
(In reply to comment #6)
> I'm not sure I like the idea of ignoring keystrokes for a short time.
> Sounds too indeterminate.  Leads to race conditions, where the delete 
> key does different things depending on how fast the user types.  Too
> hard to predict, and thus will be perceived as a bug, especially if 
> one of the things is to delete an entire address book entry.

It looks like the problem here (and bear with me, I use Macs very seldom, which is partly why I wanted you to file another bug on this) is that the Backspace/Delete key is, or would have to be, overloaded to mean two different things: "delete the selected list item" and "remove the last character from the auto-search string". I suggested disabling the former action temporarily after typing an auto-search string, so that the latter would be unambiguously correct.

> Besides, I'd rather see the delete key delete the most recent keystroke 
> of the auto-search string, as I originally expected it to do.  That's 
> a better match to other apps with auto-search of lists.  I don't have
> a Windows version of Thunderbird handy.  What does the Windows version 
> do with the Backspace key, which is in the same location on the keyboard
> as the Mac Delete key?

At present, it does nothing, actually. I would expect it to remove the last character in the auto-search string, though. There would be no conflict here, because in Windows (and Linux, and probably most other OSes), Backspace never means "delete the selected item in the list", a function reserved for the Delete key, so the problem doesn't arise.

Thunderbird never removes the last character from the auto-type string at all, though, so if you do file an enhancement, that'll be necessary first. (I can't find a bug for it right now to file a dependency on; maybe I'm just looking in the wrong place.)
I totally agree that this is a terrible problem, and there needs to be an option to curb these address book deletions. The program is simply not reliable otherwise. 

Thunderbird Address Book contacts get deleted without warning (when you accidentally hit delete), and there's no way to undo it-- how about an "are you sure?" when you delete single or grouped contact entries?
Depends on: 94407
Depends on: 650789
The STR of this bug and most of the subsequent discussion are focused on a MAC-specific problem, namely pressing MAC's DEL key in search field will unexpectedly delete address book contact instead of the last character of the search term.

-> Adjusting summary accordingly
-> Opened a new bug for the related all-platform problem:
Bug 650789 Submitted - Please add a "confirmation on delete" dialogue for address book entries ("Are you sure you want to delete the selected contact(s)?")!!!
Summary: Please add a "confirm on delete" option for address book entries... → On MAC OS, pressing DEL key in address book search deletes address book entries (contacts) without warning, instead of deleting last character of search term
Please vote for Bug 650789 using the (vote) button on top of that bug (not here), if you think there should be a confirmation dialogue before DELeting address book entries!
(In reply to comment #9)
> The STR of this bug and most of the subsequent discussion are focused on a
> MAC-specific problem, namely pressing MAC's DEL key in search field will
> unexpectedly delete address book contact instead of the last character of the
> search term.

Sorry, but I think you've misunderstood comment 0. comment 0 is not talking about the quick search facility.

If you go into the address book window, ensure the focus is on the contacts list, and then type a letter, you'll see the selection in the list jump down to the card where the first letter matches the letter you just typed. As the focus is in the contact list, that's where the delete actually happens.

Therefore resetting this bug to what it was.
Summary: On MAC OS, pressing DEL key in address book search deletes address book entries (contacts) without warning, instead of deleting last character of search term → Please add a "confirm on delete" option for address book entries...
No longer depends on: 650789
(In reply to comment #11)
Thanks Mark, it seems I did misunderstand this bug. Perhaps because it is not very obvious that people would want to delete characters from a search string that is not even visible anywhere in the UI (pls correct me if I am wrong).
Iow, this bug addresses a very special and unlikely case of the much more general case where the user is just mistaken about the focus, or accidentally hits DEL while contacts are selected.

Expected results of comment are not very clear and only have the confirmation as one option out of two. I think we are making things unnecessarily complex by having this edge case in the focus of a bug that needs to fix a major dataloss problem with a simple and straightforward solution. Instead, by focussing on this unlikely edge case we are wasting our time with discussions about time limits and so on, while the obvious solution to the real problem could be as simple as adding a 3-line confirmation dialogue to fix a 10-year-old dataloss bug. 

I don't mind keeping this one open, but in the interest of progress I do recommend to re-open the much more focussed and detailed bug 650789 that I filed to convince developers that sometimes simple solutions favoured by so many users can actually help to make TB a better product (instead of waiting for the complex solutions that are insufficient and never come).

By the way, did you bother to read the duplicate bug 650789? Does it make sense, or is it good practice, to wipe out a full list of arguments without even mentioning it here in what you want to be the main bug? While at the same time just telling users "we don't want confirmation dialogues", without any substantial reason? The net result of that approach is that a major dataloss bug is still unfixed after more than 10 years. Congratulations. This makes Thunderbird look great, and users will love you for preventing progress. Seriously, the way you handle these bugs is simply unbelievable. Sorry for being bitter, but perhaps it can make you think why generally friendly, long-term supporters like myself are turning to such sentiments...!
The cooperative and expected reaction from developers on bug 650789 could have been:
"Thank you for reminding us that we haven't managed to provide the more complex UNDO solution we promised 5 years ago. So let's go for the simple solution that so many users asked for, even though we don't think it's 100% ideal. But as we care for our users, we certainly would not want them to be exposed to an insidious dataloss bug that makes their life miserable a single day longer than necessary. Thanks for pointing out and providing good reasons for a quick and easy solution."
FTR:

Duplicate bug 650789 provides detailed arguments why complex UNDO is insufficient to saveguard against accidental dataloss, and why the simple confirmation dialogue would be a good way of solving the problem:

+++ This bug was initially created as a clone of Bug #526541 +++

Please add a "confirm on delete" option for address book entries!!!
###########################################################################
Warning: Reproducing this bug can result in permanent dataloss from your
addressbook!!! Create a new addressbook with test entries to test this!
###########################################################################

STR

1a Open the Address Book (Ctrl+Shift+B; first address book entry will
automatically be selected) OR
1b View the contacts sidebar when composing a msg
2 Read the dataloss warning above!!!
3 Create a new address book with a number of entries that can be deleted in the
next steps
4 Do not try this on a real address book!!!
5a Select a single contact (OR)
5b Select multiple contacts (they will be deleted!)
6 (optionally) scroll selected entries out of view
7a (Address book) Accidentally, hit the DEL key on your keyboard
7b (Contacts side bar) Accidentally, click the Delete Menu from context menu when you want the properties menu (very easy to miss! more bugs needed!!!)

Actual Result

5a the selected contact is silently and permanently deleted, without warning
5b all of the selected contacts(!) are silently and permanently deleted,
without warning
6 if scrolled out of view before, you do not even see them disappearing!!!
That's dataloss of the worst sort.
And there is no undo, due to bug 94407, which 10 years after filing is still
assigned to nobody, so we cannot expect a fix anytime soon.

Expected Result

Warn the user by asking for confirmation before the permanent deletion of
address book data!
I.e., show a simple confirmation dialogue like this:

[Delete Contacts]
Are you sure you want to delete the selected contact(s)?
[Delete Contacts] [Cancel]

And do NOT tell us that we should wait for bug 94407 to have an undo instead
- we have waited for 10 years without any progress, and it's far more complex
to implement than this one, and we are sick and tired of waiting any longer to
protect our addressbook data
- more importantly, bug 94407 does NOT solve the problem of this bug(!), as has
been said ever-so-often in the respective comments, and it's still true, as I
shall show below.

Reasons:

1) Address book data are valuable data that require best protection
8) The default behaviour should be 100% fool-proof. UNDO is NOT fool-proof,
because unless we go for another more complex UI, the average user will not
know where to look for undo.
2) UNDO function does NOT help, because:
Most of the time that this accident happens, especially with single entries,
the user is likely to not even notice that an address book entry has been
deleted. Much more so as if the selected and deleted entries happen to be out
of view. If the user notices later, he will have no ideas why, and will falsely
blame a bug in Thunderbird that it mysteriously loses addresses.
3) Deletion of important data should ALWAYS come with a warning.
4) Deliberate deletion of individual contacts is a RARE use case for most
users, so there is no problem to ask for confirmation. Most people don't
usually delete lots of individual entries from their address book.
5) Even for deleting multiple non-adjacent entries in a row, one by one just
because you so wish, this just adds ONE single, simple keystroke for each
deletion: ENTER. Otherwise, use the method of No. 6!
6) For multiple entries, user can select them (with shift or ctrl), and press
DEL ONCE, and confirm with ENTER ONCE. No fuss, no nothing. Where the ... is
the problem?
7) If you think this should be configurable, let's have a hidden preference for
a start. Do not implement an UI (like "never ask this again" etc.) because that
will delay this bug another 5 years.
8) In any case, it's better to have a few people complain about an extra
keystroke, than have a lot of people suffer from (potentially unnoticed)
permanent dataloss. Iow, avoiding dataloss outweighs a little inconvenience!
9) Needless to say, permanent dataloss without warning is a big problem:
- Even if the user does notice immediately, he may not easily be able
to determine which entry was deleted, in order to add that entry back.
- Even if he knows which entry was deleted, he may not know the e-mail
address or other info that was stored for that entry, or which mailing
lists that entry was on, so he will be unable to reconstruct the data.
10) If the user accidentally pushes the DEL key a little longer (or something
falls on the keyboard or whatever, think of accidents!), he might wipe out his
whole address book without confirmation. NO, NO, NO! We do need confirmation
here!!!

Conclusion:

C1) UNDO is not implemented, and we have no reason to assume it will be any
time soon. Furthermore, UNDO doesn't help because accidental deletion, by its
nature, might easily happen unnoticed, and is too difficult for the average
user. So we need another solution, and we need it NOW!
C2) Not asking for confirmation before deletion of address book data, currently
permanent deletion, creates the potential for silent and unnoticed deletion of
single or multiple contacts, even the whole address book (very easy with the
current wrong design of the context menu in contacts side bar):
This bug is really CRITICAL, and should BLOCK!
C3) A simple confirmation dialogue does not need a lot of coding: After more
than 10 years, please FIX THIS to stop the dataloss, and stop debating and
daydreaming about complex undo functions that never see the light of day and
would not even solve the problem!

N.B. I took some ideas/wording from related/duplicate bugs on this issue.
N.B.2: I am a power user, iow quite aware of focus and the nature of this bug.
Yet, while testing for this bug, I ran into the scroll trap and accidentally
deleted one address book entry for good, without knowing which one it is!
Sorry, but this is really annoying, especially because so many users throughout the years have asked for the simple confirmation dialogue, just to be ignored!
Thomas: I have read that bug, and I was planning on discussing this with drivers later in the week (hence why I moved the status-thunderbird3.1 request rather than just cancelling it), but I didn't want to reply to it in detail at the time as I was busy working through other things (although I should have probably mentioned that explicitly).

I also consider your comment as very borderline on whether or not it is acceptable under our etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html), I realise that you may find this issue frustrating, but please remember that we need bugzilla to be a friendly place where we can all work together.
This feature is also requested on getsatisfaction:
http://getsatisfaction.com/mozilla_messaging/tags/bug_526541
Users there seem to be equally frustrated...

Thank you for taking this up with drivers, that's good news!
I overlooked the new status-thunderbird3.1 request flag that indicates developer's interest in the topic, sorry.

OT: ...yes, it might be borderline on the etiquette, and I could see that reference coming (which is annoying again, as I am basically trying to help, and you know that), but I am starting to wonder what the alternatives are to me, if it's perhaps something between occasionally venting but otherwise keeping up the extensive and painstaking work and support that I do for Thunderbird, or, alternatively, eventually giving up on the whole story because it just makes you go insane...
How about venting somewhere other than in Bugzilla?  (Eg private email, a personal blog, ...).
(In reply to comment #18)
> How about venting somewhere other than in Bugzilla?  (Eg private email, a
> personal blog, ...).

That's certainly more appropriate. Frustration got the better part of me yesterday night, sorry for the noise. But I really hope we can be more flexible and faster in getting such long-term annoyances out of the way in the future.
Version: 3.0 → Trunk
Assignee: nobody → mconley
Attached patch Patch v1Splinter Review
Asking for ui-review for the added strings.

I've also added some regression tests for this, and still waiting on results from Try:  http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=1528381a5e83
Attachment #533027 - Flags: ui-review?(bwinton)
Attachment #533027 - Flags: review?(mbanner)
Try server shows green on all platforms for xpcshell and Mozmill.
Comment on attachment 533027 [details] [diff] [review]
Patch v1

Review of attachment 533027 [details] [diff] [review]:
-----------------------------------------------------------------

In the existing patch, we display the dialog when I hit the "Delete" button on the toolbar, and I don't think we want to do that.  Although, we can't undo that deletion either, so perhaps that's okay.

I guess, ui-r=me, but I expect to be yelled at for showing people an extra dialog.  :)

Thanks,
Blake.
Attachment #533027 - Flags: ui-review?(bwinton) → ui-review+
Comment on attachment 533027 [details] [diff] [review]
Patch v1

I forgot that Standard8 has been busy with his move - so I'm switching my reviewer request.
Attachment #533027 - Flags: review?(mbanner) → review?(dbienvenu)
Comment on attachment 533027 [details] [diff] [review]
Patch v1

I tried this by hand and it worked fine - mozmill isn't currently working for me.
Attachment #533027 - Flags: review?(dbienvenu) → review+
Cool cool - thanks for the review.  Added checkin-needed tag.
Whiteboard: [GS] → [GS] [checkin-needed]
Keywords: checkin-needed
Whiteboard: [GS] [checkin-needed] → [GS]
Checked in: http://hg.mozilla.org/comm-central/rev/e79d3d86eab0
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.4
Has the patch for this bug fixed the problem for the contacts sidebar of mail composition, too? I.e., will I see a confirmation dialogue if I presss DEL on selected contact(s) in contacts sidebar (F9)?
Blocks: 343973
>  I.e., will I see a confirmation dialogue if I presss DEL on selected 
> contact(s) in contacts sidebar (F9)?

No, you won't - but I don't believe the contact will be deleted either.  On my machine, pressing delete in the contacts sidebar with a contact selected has no effect.  In order to delete a contact, I have to right click on it, and choose "Delete".
(In reply to comment #29)
> >  I.e., will I see a confirmation dialogue if I presss DEL on selected 
> > contact(s) in contacts sidebar (F9)?
> 
> No, you won't - but I don't believe the contact will be deleted either.  On
> my machine, pressing delete in the contacts sidebar with a contact selected
> has no effect.

Bug 343973 - Contacts sidebar: Implement keyboard shortcut to delete selected contact(s), e.g. [DEL]

> In order to delete a contact, I have to right click on it,
> and choose "Delete".

So then, will choosing "Delete" from contacts side bar context menu produce the confirmation dialogue?
> So then, will choosing "Delete" from contacts side bar context menu produce 
> the confirmation dialogue?

At the moment, no, it does not - except for mailing lists.

It probably should bring it up for standard contacts though.
Blocks: 665267
(In reply to comment #31)
> > So then, will choosing "Delete" from contacts side bar context menu produce 
> > the confirmation dialogue?
> At the moment, no, it does not - except for mailing lists.
> It probably *should* bring it up for standard contacts though.

yes, especially because there is no undo (see Blake's comment 23)

-> followup Bug 665267 - Contacts Sidebar: Please add a "confirm on delete" option for address book entries
No longer blocks: 665267
Depends on: 665267
See Also: → 94407
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: