User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 When you select a message of a group of messages and press SHIFT+DEL the messages are completely deleted without going to the trash can and as such cannot be undeleted. In this situation, a confirmation dialog should be displayed. Reproducible: Always Steps to Reproduce: 1. Select a single message or a group of messages. 2. Press the SHIFT+DEL key combination. Actual Results: The messages were permanently deleted. Expected Results: Before permanently deleting the messages there should have been a confirmation dialog as in MS Outlook Express ou Microsoft Office Outlook.
I forgot to mension that I was using Mozilla Thunderbird 1.5 Beta 1.
Ever since netscape 4.x, shift delete has meant delete it ASAP, no trash, no confirmation. Please don't use shift delete if you want confirmation.
The fact that it is working like that since Netscape 4.x doesn't make it right. It is perfectly possible that you may, inadvertedly, drop something on the keyboard which causes that killer combination to be pressed, as the keys are located next to oneanother and without other keys in between. I think that avoiding this perfectly possible and highly undesirable situation more compensates for forcing the users to make that extra effort and press ENTER to accept the confirmation. In Microsoft Internet Explorer you even have to explicitly press Y because the default button in the confirmation dialog is NO! If you think this should be changed to an enhancement then feel free to chage it.
(In reply to comment #3) >... > If you think this should be changed to an enhancement then feel free to chage it. This would be an example of a reason for having backups. WONTFIX IMO
*** Bug 358998 has been marked as a duplicate of this bug. ***
The duplicate suggests a confirmation dialog with a "Don't show this again" checkbox.
Bug 62448 is the Seamonkey equivalent, which was WontFix'd.
Even as a conscious user with full awareness of what shift+del is meant to do (permanent deletion), I absolutely want a meaningful confirmation message because it can happen so easily - *especially* when you know the shortcut - that your fingers are too fast and you end up deleting too much or things you didn't intend to. I am not aware of any program that does NOT ask for confirmation before permanent deletion. I support Mike's suggestion to implement "Don't show this again" because I think it will cater best for both the speed freaks and the security oriented users. But security should definitely go first. To suggest backups to "avoid" this bug is not exactly helpful at all, for you would need data backups every minute to avoid accidents with shift+del. Please implement some useful information into the confirmation dialogue like "You are about to delete 15 messages from folder inbox. Continue?"
Bug 326869 is related to this bug and also suggests implementing the confirmation dialogue. (in reply to David's comment #2) > Ever since netscape 4.x, shift delete has meant delete it ASAP, no trash, no > confirmation. Please don't use shift delete if you want confirmation. Not using shift does NOT solve the problem for those users who *want* permanent deletion (rather than filling up junk folder) *but also want* that extra second to think about the decision to avoid data loss. Another option, as suggested elsewhere, would be to introduce UNDO for expunge, since even shift-deleted messages are still in the folder file until the next compacting as we know. "It has always been like this is" is certainly no argument against improvement, agree with Nuno Gonçalo. Except lack of time or other priorities, are there any substantial arguments against the "Don't show this again"-dialogue-solution?
typo correction: ...(rather than filling up TRASH folder)...
(In reply to comment #7) > Bug 62448 is the Seamonkey equivalent, which was WontFix'd. Not quite: Bug 62448 was a pragmatic / conditional WontFix'd. The (only) argument of bug 62448 for WontFix was that investing work into the confirmation message will be less urgent / less needed in view of the (expectedly "soon") pending fix for bug 132121 (Can't undo shift delete of local messages). However, that bug has been open for 5 years and still is (and ever shall be...?). I find it kind of strange to use an open bug that requires a /complex/ bugfix (bug 62448) as an argument for WontFix of another bug/rfe that would be far easier to implement (this one, bug 308690), while there are no substantial arguments against that little "confirmation" rfe except for bug 132121's pragmatic argument of skipping the work for the small patch: "I think it would be better just to fix undo for local folders than to put this patch in." (D. Bienvenu, comment #17). In other words, the wontfix argument runs like this: "To avoid a little work, let's not do the small and obvious change ("confirmation message" for the average user w/ "don't show this again"-option for the freaks), for which a patch was already on the way, but let's wait for the big bug to be patched ("undo shift+del"), and, meanwhile, use the pending fix of the big bug at some unforeseeable point of time in the future as a justification not to do the small rfe..." - Admittedly, a good way of ensuring that we will see no progress on the matter whatsoever. :-| Sorry, but... Combine this with the fact that bug 326869 calling for a *visible/accessible* (e.g. menu) implementation of shift-deleting messages is also still unconfirmed, and I can't help the impression that some people are happy already when things work "as they always have since the days of Netscape" for knowers or freaks but somewhat arbitrarily and without good reasons refuse or ignore the average user's wishes for sensible improvements over the status quo? Maybe this is the wrong place for such feelings, but the more I get into it and read some of the age-old bugs and suggestions, the more it appears to me that there may be a pattern that is not just a matter of lack of time. And if I wasn't freaky about Thunderbird myself and loving it as the best thing out there for emails, I wouldn't complain... ;-) Keep it going, guys! Please do!
(In reply to comment #3) > The fact that it is working like that since Netscape 4.x doesn't make it right. "Shift+Del since netscape 4.x" is completely same as one in Windows Explorer. Nuno Gonçalo Brito, no experience of Shift+Del on Windows Explorer? Question to Nuno Gonçalo Brito(bug opener) and Thomas D.: Do you think following is right thing? - add confirmation - then need to add new feature to kill it to prevent annoyance of many users - after that, request for one click way to come back to confirmation display Enhancement by bug 132121 is not sufficient for undelete just after Shift+Del by mistake?
(In reply to comment #12) I don't know if I understood your question right. In Windows Explorer, pressing SHIFT+DEL deletes files permanently but asks you for a confirmation before doing so. Pressing DEL should move messages to the trash folder and no confirmation is needed in this case. Pressing SHIFT+DEL should delete messages permanently, i.e. not sending then to trash, but only after the user is given a change to confirm it. Lets be honest, if you press SHIFT+DEL you are using the keyboard. Is it really such a big annoyance to force the user to simply press Y after it?!
(In reply to comment #13) > Is it really such a big annoyance to force the user to simply press Y after it?! Yes, it's big annoyance for me, because I know "what Shift+Del is" well since before Netscape 4.x era, and I intentionally use Shift+Del, and I frequently use Shift+Del, not only on Thunderbird but also on MS Win's Windows Exploler. Further, I know how to recover "Shift+Del"ed mail, Shutdown Tb, and change X-Mozilla-Status: 0008(or 0009) to 0000(or 0001), and change length of a mail by adding a space to X-Mozilla-Keys:, Subject: and so on (in order to bypass mail.db_timestamp_leeway=4000), then restart Tb (and click folder to bypass incorrect count display bug). So "Shift+Del of mail by my mistake" will never be big problem for me :-)
I want to support WADA here. I'm dead against adding a confirmation on Shift/Del. I need Shift/Del to work, and work fast, when sorting through mailboxes with hundreds of new mails per day. I must already use it repeatedly just to delete a block of uninteresting threads, because of bug 65111. Popping up a confirmation message everytime on top of that would be an enormous annoyance. Also, what happens if you type Shift/Del a hundred times and have to confirm each one? You do it automatically. So the hundred and first time you hit it automatically too, before noticing that you didn't want to delete that one after all. Security gain: zilch. Wrt comment #8: there are plenty of programs out there which delete data much more permanently than SeaMonkey Mail/Thunderbird's Shift/Del without any confirmation, starting with good old "rm". Yes, I know that some people have the awful habit of aliasing "rm" to "rm -i". I also know that as a protection against data loss by inadvertent deletion, it doesn't work at all. Is there a way to antivote - ie. to vote for a bug to be set to WONTFIX?
No, this bugzilla doesn't have negative votes. I think we can agree bug 132121 would be the fix...
[I marked bug 430796 as duplicate of this one cause it was only about shift del..)] There is (!) an alert for shift+del messages on version 220.127.116.11 (20080213) but missing in version 3.0a1pre (2008042303) I consider it subject to accidental data loss, and having an alert is all you need to step back if accidentally shift del. I think alert should be there for accidental reasons, while having an undo for shift del is inconsistent with OS UI (no undo in shift del in win) and undermines the very purpose of intentional shift del (skip trash, forever del) Having undo for multiple, all msg shift+del may be harder to implement than an alert and if that alert will eventually get a check for "don't show this again" and a pref, it should not work for many/all msg. Meaning it should be a different alert like "You are about to permanently delete a LARGE # of data" or "all mails in hte folder will be PERMANTLY deleted" Harder or not, if you like undo for shift+del better, that should probably be related to a kind of "recovery" or "restore" rather than usual undo. IMHO
@ovidiu: No alert to be seen in 18.104.22.168 (20080421) either Should be there, as the OS and other apps work in the same manner: - delete = don't warn and move to trash (which allows you to undo your action) - shift+delete = warn and delete permanently
agree to comment #19, consistency with OS .. If someone needs other options aside default OS behavior, this should stay as extension. Well, there is an extension "Confirm before Delete" https://nic-nac-project.org/~kaosmos/index-en.html#cbd but not present in amo unfortunately, as all other great extensions there. !!I was using that in TB 2, so my comment #18 is not accurate. There's no alert for shift del by default!
[5 duplicates/equivalent/mentioning bugs in favour so far] [ovidiu and bramus also in favour of an (optional) confirmation message] Nuno Gonçalo Brito has a considerable thought for this one: > Since there seems to be so much controversy and very strong opinions about this > wouldn't it be possible to make it configurable? That way everybody would be > happy! In the same spirit, to those of you who are "dead against" a confirmation msg before permanent deletion: While I appreciate the emotion: Are there any substantial reasons against making the confirmation msg "optional"(!) by including a "don't show this again" checkbox? So nothing will change for you, but it will be better and safer and more consistent for the rest of us... I'm inclined to agree with ovidiu that "undo for permanent deletion" seems like a contradiction in itself and is also inconsistent with the OS (shift+del of files is NOT undoable). I think undo RFE (bug 132121) and this RFE are different and do not outweigh each other. I posted a detailed summary of arguments and specific suggestions for a "configurable" compromise that might make everyone happy, in the other thread ("undo RFE", bug 132121, comment #20)...
Reporter or someone with the powers, please add "dataloss" keyword, for the average user will be unable to recover anything deleted by accidentally hitting shift+del, as WADA illustrated in comment 14 :-) (So it's dataloss at least for as long as undo RFE, bug 132121, is not done AND still under discussion) This bug's current description ("No confirmation msg...") shows it was intended as a bug, not an enhancement. If it's enhancement, though, description ought be changed: "*Show* confirmation message when..." (and just one "when" will do).
I'll assert that this is a bug, given that bug 132121 has not been fixed.
For me this is a bug, not a request for an enhancement. I use shift-delete all the time but every so often I use it on a file I did not intend to delete. An extra keystroke to confirm permanent deletion is no huge problem for me. It is important to note that nearly all other programs that use shift-delete ask for a confirmation so the confirmation dialog box is considered the norm. Given that many people have requested this fix over a long period of time I think it should be done.
Blake, what are your thoughts on this? While shift-delete is usually (but not always) undoable, it's also not obvious that it would be. Shift-delete in other contexts is usually a permanent action. We could, of course, add a "don't ask me again" checkbox for people who don't like the change. We should also figure out how this would interact with the warning you get when deleting collapsed threads.
Oh, I should also mention: if we add a warning prompt, then we can flip the pref that currently hides the delete button in newsgroups, which would be nice.
Yeah, while I'ld like to have it be undoable, it seems like warning users would prevent at least some dataloss. (Although I strongly suspect Peter will still delete things he didn't mean to, once hitting enter after shift-delete becomes habit… ;) If we do add the prompt, having a "Don't ask me again" checkbox seems reasonable, and consistent with other dialogs we have.
I agree with everything you say Blake. As you and others have suggested have a "Don't ask me again" checkbox for power users and also make it undoable.
One more question: what should we do when we shift-delete a collapsed thread? Currently, we show an alert for that warning about collapsed thread operations. Should we show that prompt, or the new prompt that will address this bug? (Or some third prompt combining the two?)
I'm happy with showing the existing prompt.
I was thinking we could use some strings for both of the prompts. Here's what the current collapsed-deletion warning looks like: +- Confirm Delete of Messages in Collapsed Thread(s) ---------- x + | | | [ ? ] Warning - this will delete messages in collapsed | | thread(s) | | [x] Always ask me before deleting messages in collapsed threads | | [ Cancel ] [ Apply ] | +-----------------------------------------------------------------+ These strings aren't very clear to me (besides being a bit redundant). How about something like this? +- Confirm Deletion ---------------------------------- x + | | | [ ? ] This will delete messages in collapsed threads. | | Are you sure you want to continue? | | [ ] Don't ask me again | | [ Cancel ] [ Delete ] | +--------------------------------------------------------+ Then we can reuse most of those strings for the new prompt: +- Confirm Deletion ---------------------------------- x + | | | [ ? ] This will delete messages immediately, without | | saving a copy to Trash. Are you sure you want to | | continue? | | [ ] Don't ask me again | | [ Cancel ] [ Delete ] | +--------------------------------------------------------+ Thoughts?
In reply to comment #33: It isn't as obvious as you think. For instance, let's say you reuse strings, as "This will delete messages" "in collapsed threads." "immediately, without saving a copy to Trash." "Are you sure you want to continue? Now the reason we have distincts strings is because we have translations. Let's say that in one language the adverb must come before the verb, as in [This] [immediately] [willdelete] [messages,] etc. There's no way it will be possible to make the translation into that language look natural to a native with the threads we just assumed that you are reusing. For the other strings it will probably be easier, but I guess it would be better to have someone from l10n voice an opinion.
I don't think that's what Jim meant. I think he meant we could re-use "Don't ask me again", and possibly "Are you sure you want to continue?"… I like switching the question from "Always ask me" to "Don't ask me", since that's more consistent with other places we ask similar questions.
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #35) > I don't think that's what Jim meant. I think he meant we could re-use > "Don't ask me again", and possibly "Are you sure you want to continue?"… All right. Just let's make sure that we won't reuse strings in ways the localizers wouldn't like. > > I like switching the question from "Always ask me" to "Don't ask me", since > that's more consistent with other places we ask similar questions. Yes… and yet. http://mxr.mozilla.org/comm-central/search?string=Always+ask finds more other examples than I would have thought, and even after disregarding comments there still remains a sizable number of them.
Right, what Blake said. Specifically, I want to reuse "Confirm Deletion", "Don't ask me again", and "Delete". The rest of the text will be totally separate. I think "Don't ask me again" makes more sense, *in this particular case*, since it expresses a particular thought a user might have ("how do I get rid of this thing?"). Phrasing it as "always ask" forces you to invert the logic in your head. For people who want the status quo of a confirmation prompt, they can just ignore that text.
Created attachment 651074 [details] [diff] [review] Fix this (no tests for now) Ok, here's a patch. I should probably add a couple of tests, but I'll do that over the weekend.
Comment on attachment 651074 [details] [diff] [review] Fix this (no tests for now) >+++ b/suite/locales/en-US/chrome/mailnews/messenger.properties You'll want a SeaMonkey person to review this part, but other than that, I like it. f=me.
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #39) [...] > You'll want a SeaMonkey person to review this part, but other than that, I > like it. f=me. I see that Mnyromyr already gets bugmail from this bug. Otherwise you (squib) might be interested in http://www.seamonkey-project.org/dev/project-areas http://www.seamonkey-project.org/dev/review-and-flags
With the current proposed solution, I can see myself getting into the habit of pressing SHIFT+DEL Y in one stroke, thereby losing the extra second of thought. May I suggest, as a compromise between speed and safety, that Thunderbird only ask if more than say 5 messages are SHIFT-DELeted with a message like "You are about to delete a large number of messages with no way to recover. Are you sure?" The particular number could be made configurable and default to 1.
I support the calls for a SHIFT+DEL warning message with a "Don't ask me again" checkbox.
Created attachment 709335 [details] [diff] [review] Add tests Ok, I fixed some bitrot and added Mozmill tests for this. Should I also get a Seamonkey reviewer on this, since I changed strings?
Jim, could you add a screenshot?
(In reply to Sean M. Pappalardo from comment #41) > With the current proposed solution, I can see myself getting into the habit > of pressing SHIFT+DEL Y in one stroke, thereby losing the extra second of > thought. > > May I suggest, as a compromise between speed and safety, that Thunderbird > only ask if more than say 5 messages are SHIFT-DELeted with a message like > "You are about to delete a large number of messages with no way to recover. > Are you sure?" The particular number could be made configurable and default > to 1. +1. I like that idea very much. However, I think we need a new bug for that, based on the situation after this bug lands, with steps, actual result, and expected result.
Jim/Blake, for both simple and power users, it would be great to know *how many* messages are going to be permanently deleted, ux-consistent with deleting files in OS file managers (e.g. Windows explorer: "Should these 5 elements really be moved to trash?"). Is it possible to get the count, and include that into the confirmation strings, with %S as a placeholder for the number? # LOCALIZATION NOTE (confirmMsgDelete.collapsed.desc, # confirmMsgDelete.shiftDel.desc): Insert "%S" in your # translation where you wish to display the number of messages which will be # deleted +confirmMsgDelete.collapsed.desc=This will delete %S messages in collapsed threads. Are you sure you want to continue? +confirmMsgDelete.shiftDel.desc=This will delete %S messages immediately, without saving a copy to Trash. Are you sure you want to continue? This will also reduce the ambiguity of warning "This will delete message_s_ immediately" (plural, i.e. more than one msg) even when just one message will be deleted.
Unfortunately, you can't easily do pluralization in C++ code, since the pluralizer was written in JS. I don't have the time to figure out a way around that, but anyone who'd like to make a followup to this is free to.
(In reply to Jim Porter (:squib) from comment #47) > Unfortunately, you can't easily do pluralization in C++ code, since the > pluralizer was written in JS. I don't have the time to figure out a way > around that, but anyone who'd like to make a followup to this is free to. I'm not sure I understand. Can you explain "pluralization"? Is it about grammatical plural forms of strings like "1 message" vs. "5 messages"? I was not asking for correct grammatical pluralization, but what about just adding the message count into the strings, using the same system with %S placeholder in the string that we are already using in many other places? Regardless of the coding language, I'd think it should be possible to parse "stringpart1 %S stringpart2" as "stringpart1 " + numofmessages + " stringpart2" or iow, just to replace "%S" in the string with the calculated number of affected messages.
That's resulting in wrong language in many cases, see https://developer.mozilla.org/en-US/docs/Localization_and_Plurals for examples.
Comment on attachment 709335 [details] [diff] [review] Add tests ui-r=me! Thanks, Blake.
Someone bug me if I haven't landed this by Friday (I haven't committed to comm-central in a while, and need to renew my HG commit privileges).
Ok, HG privileges bug filed finally (don't make promises to do things before work weeks!): bug 865224
It's been a while since I wrote this, so I'm running a try build to make sure nothing broke: <https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=2e47f81850fb>. Hopefully, I'll be able to land this later today.
Tests look good, though the tree seems to be closed: "remote: Tree Seamonkey comm-central is CLOSED!" (it claims to be open on TBPL).
Well done. Thanks people. I have been using this for some time now and it is perfect.
(In reply to Peter B from comment #56) > Well done. > Thanks people. I have been using this for some time now and it is perfect. Glad to hear that, Peter, thanks!