Using 2000-08-16-08 commercial build on NT 1. Select a mail message in the thread pane 2. Hold down the Shift key and press the Delete toolbar button Expected: message to be deleted without copying to Trash Actual: message is deleted, but also copied to Trash
Add keywords 4xp, regression, perf, nsbeta3. I love keywords!
Keywords: 4xp, nsbeta3, perf, regression
I don't think this is a regression. Using shift-delete on the keyboard seems to work for me. I never made it work for the shift key and the delete toolbar button. In 4.x hitting shift and the toolbar button delete also seems to copy to the trash.
I'm stunned, but you're right. I think that's a bug in 4.x. Adjusting keywords
Keywords: 4xp, nsbeta3, regression → polish
Summary: Shift-Delete broken → Make shift-delete work with toolbar button
moving to future milestone.
Target Milestone: --- → Future
QA Contact: esther → sheelar
The "shift" doesn't seem to have any impact on this, it moves to the thrash anyway. Build 2001010504, Windows 98.
By the way, shift-delete is a feature; not a bug as far as I know. It's a fast way to delete a message without being forced to first move it to trash the empty trash. I am suggesting this as a wontfix.
Håkan, there are plenty of features filed in bugzilla -- I don't think this means it should be closed. Having the bug marked MFuture means Scott isn't going to get to it any time soon, but that it's a legitimate improvement that someone could make, if they were interested.
Severity: normal → enhancement
I think I *could* make this improvement, but I think it should stay as it is. That was my point with my latest post. I think we should have it as it is, and just let it be. I know a lot of people who actually liked this "feature" in NS4.x.
They liked that shift-delete works with the keyboard, but not the toolbar button? IMO, this is inconsistent behavior, and we should fix that. Personally, I use shift-delete all the time, and have trained myself not to use the toolbar Delete button for that reason.
reassigning to ssu.
Assignee: putterman → ssu
For YEARS I have been wondering why I couldn't use shift-delete to delete messages without putting them in the trash can. This should be pretty easy to fix. Sean Su, Håkan--let me know if you need assistance. Can we at least reset the milestone for 1.1 or ?
OS: Windows NT → All
Hardware: PC → All
*** Bug 86660 has been marked as a duplicate of this bug. ***
nominate for nsbeta1
Assignee: ssu → sspitzer
Keywords: nsbeta1 → nsbeta1-
This is a work in progress patch to solve this bug and cleanup the code for deleting messages/message folders on the way.
Assignee: mail → aqualon
Status: NEW → ASSIGNED
Priority: P3 → --
QA Contact: mail
Target Milestone: Future → seamonkey2.0alpha
The patch fixes the following issues: - Clicking the delete button with pressed shift key deletes messages and doesn't move it to the trash (like for shift-delete key). - shift-delete with focused folder and selected message doesn't delete the message anymore. Following things were changed for the patch: - DefaultController doesn't delete the message directly, but uses mailWindowOverlay.js' MsgDeleteMessage(). - Delete button calls MsgDeleteFromToolbar(event) and that function decides, if and how a message or a folder is to be deleted. - MsgDeleteMessageFromMessageWindow() was removed from messageWindow.js, cause MessageWindowController can also use MsgDeleteMessage(). Saves duplicated code for doing the same thing. - Some indentation glitches were fixed.
Comment on attachment 276115 [details] [diff] [review] Fix the bug and cleanup of message deletion code This makes it so that the Delete button cancels messages. Is that intentional? What was wrong with making the delete button's oncommand be this: goDoCommand(event.shiftKey ? "cmd_shiftDelete" : "cmd_delete"); You don't want to call goSetMenuValue for cmd_shiftDelete.
I just assumed that you were going to do what Neil suggested - that's pretty simple...
(In reply to comment #17) > What was wrong with making the delete button's oncommand be this: > goDoCommand(event.shiftKey ? "cmd_shiftDelete" : "cmd_delete"); Nothing, I just didn't know it's that easy to do :) I still think some of the code cleaning is useful, but that should probably be made in another bug. One question, at the moment shift-delete (and shift-'button_delete') delete the selected message even when there's focus on the folder pane (while just delete asks the user, if the selected folder should be moved into trash). Is that intentional or is it a bug? I would prefer, that shift-delete shows the equal behaviour to delete, hence delete the selected folder. Deleting the selected but not focused message without a chance to get it back from the trash seems to be a bad idea.
(In reply to comment #17) > (From update of attachment 276115 [details] [diff] [review]) > This makes it so that the Delete button cancels messages. Is that intentional? Do we ever show the delete button for newsgroups? Preventing something that never occurs seems to be quite redundant.
Attachment #276115 - Attachment is obsolete: true
(In reply to comment #20) >One question, at the moment shift-delete (and shift-'button_delete') delete the >selected message even when there's focus on the folder pane (while just delete >asks the user, if the selected folder should be moved into trash). To fix that, simply add cmd_shiftDelete to the folder pane controller.
Comment on attachment 276131 [details] [diff] [review] Simple fix I wrote this in comment #17. How can I review it?
(In reply to comment #21) >Do we ever show the delete button for newsgroups? Preventing something that >never occurs seems to be quite redundant. A good point. Let's remove that code too while you're at it.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Attachment #276131 - Flags: review?(neil) → review?(bienvenu)
I think that was closed accidently, reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 276131 [details] [diff] [review] Simple fix thx, loooks good.
Attachment #276131 - Flags: review?(bienvenu) → review+
Status: REOPENED → ASSIGNED
Keywords: perf → checkin-needed
Checking in mailWindowOverlay.xul; /cvsroot/mozilla/mailnews/base/resources/content/mailWindowOverlay.xul,v <-- mailWindowOverlay.xul new revision: 1.334; previous revision: 1.333 done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.