666934 - Usability enhancement: delete next to print on context menu

Status: RESOLVED DUPLICATE of bug 837205

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Joey Armstrong [:joey]]

When a user selects several messages to apply an action against some interesting behavior can surface:

Select a mail folder with several messages { cruft=100+ }
click to select one message in the folder.
type ctrl-A to select all mesasges in the folder
right click for a pulldown menu of options
Selectable options are adjacent: Print... & Delete Selected Messages
Aim a little too high in the menu, select 'print' rather than 'delete'.

80+ messages begin spooling.
Have fun trying to cancel a stream of dialog boxes from the print spooler.

If user modifiable config options could be added:
  o message.max.delete = 50
  o message.max.print = 5

Then when the selected number of messages exceeds this threshold, present the user with a dialog box -- to cancel, allow or modify the config setting -- recovery from a mishap would be far less painful.

Comment 1

[Wayne Mery (:wsmwk)]

methinks this is what pausing a print queue is for :)

anyway, unless someone like bwinton wants to decide the fate of all of these in one bug, this truly is three different ENH bug reports (though perhaps the context menu is not ENH). Can you split two of them off please? Though it seems unlikely we'd add preferences for something like this - I'll bet there already is a wontfix bug for message.max.delete

Comment 2

[Joey Armstrong [:joey]]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> methinks this is what pausing a print queue is for :)

From a usability standpoint forcing users to rely on external programs in order to correct a problem seems a bit odd.  If [n] messages are selected and some other action like reply/reply all is mistakenly selected what then ?  Yes, in this case the user now has 50+ windows to close if they are not able to log out or reboot.


> anyway, unless someone like bwinton wants to decide the fate of all of these
> in one bug, this truly is three different ENH bug reports (though perhaps
> the context menu is not ENH). Can you split two of them off please? Though
> it seems unlikely we'd add preferences for something like this - I'll bet
> there already is a wontfix bug for message.max.delete

new bugs to be opened and attached shortly.