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



18 years ago
10 years ago


(Reporter: jruderman, Unassigned)


(Blocks: 1 bug, {polish})


Firefox Tracking Flags

(Not tracked)




18 years ago
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

18 years ago
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.
In what situations is a mail folder not renameable or not deleteable?

Comment 3

18 years ago
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.
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
Keywords: 4xp

Comment 5

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


18 years ago
Keywords: polish

Comment 6

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


17 years ago
QA Contact: esther → olgam


17 years ago
Blocks: 158011

Comment 7

15 years ago
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

15 years ago
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

15 years ago
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 

Product: Browser → Seamonkey


14 years ago
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: olgam → message-display
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?
OS: Windows 98 → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.