67605 - "rename" and "delete" should be shown on all folder context menus, even if disabled

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jesse Ruderman]

Currently, if a mail folder cannot be renamed or removed, the items "rename 
folder" and "delete folder" aren't shown on the context menu for that folder.  
I think it would be better to always show those items, but just have them 
disabled for folders that cannot be renamed/deleted.

See also bug 54446, "File|Rename folder should be disabled when the Sent folder 
is selected".  I don't understand why that would happen for some permanent 
folders and not for others...

Comment 1

[timeless]

see also mac discussion for disabled and hidden.

I think we need to use a style so that the platform css can control whether a 
disabled item is hidden or visibly disabled.

I guess that means context menus should use .disabled and then the css for 
macos would use :disabled {display:none} or something similar.

Comment 2

[Matthew T (active 1999-2002)]

In what situations is a mail folder not renameable or not deleteable?

Comment 3

[Jesse Ruderman]

Most of the default folders (Inbox, Sent, etc.) can't be renamed or deleted.  
Maybe that's the real problem, although you would need some way to re-create 
the special folders if you deleted them.

Comment 4

[Matthew T (active 1999-2002)]

For renaming, see bug 24064.

For deletion, 4.x had alerts:
* `You cannot move your Inbox Folder.'
* `Are you sure you want to move Drafts away from its default location? Next time
  Communicator runs, a new Drafts folder will be created in the default
  location'

Comment 5

[timeless]

there's a bug about mailboxes not being l10n safe when that arch is fixed 
renaming this stuff should be ok.

Comment 6

[Jesse Ruderman]

See also bug 39194, Should disable "Rename Folder" menu/context menu for IMAP 
mail fodler & special folders.

Comment 7

[Mike Cowperthwaite]

I would wontfix this bug.  Context menus, by definition, are supposed to be 
constructed according to their context.  Deleted items in a context menu make 
little to no sense.

Jesse, what do you think?

Comment 8

[timeless]

the problem is that if you don't show the user they can't do a certain action,
they might just think that the context menu was giving them some other type of
action list. Showing them that the item would normally apply but isn't enabled
hints that there's some reason they can't take the action. and if we could do
statusbar items you could even explain why the action is disabled.

anyway i'm not sure where i actually stand wrt this bug...

Comment 9

[Mike Cowperthwaite]

In my comment 7, I wrote
> Deleted items in a context menu make little to no sense.

I meant, of course, "*Disabled* items..."

And today I read a spec on Mozilla which argues (in favor of this bug) that 
items in similar context menus *should* be disabled, not hidden, so that the 
user's "muscle memory" doesn't fail by moving to a menu position that was 
unexpected:

 http://www.mozilla.org/projects/ui/menus/shortcut/

Comment 10

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090613 SeaMonkey/2.0b1pre - Build ID: 20090613000642

I can reproduce on Linux => Platform to "All". Otherwise I don't know where I stand wrt this bug. Comment #7 and comment #8 both make sense to me. Any hope of having this bug either WONTFIXed or FIXED someday?