102340 - Ridiculous number of separators in bookmarks context menu

Status: RESOLVED FIXED

(SeaMonkey :: Bookmarks & History, defect, P5)

Description

[Hixie (not reading bugmail)]

Currently:
   +-------------------+
   |Open               |
   |Find a Bookmark... |
   +-------------------+
   |Cut                |
   |Copy               |
   |Paste              |
   |Delete             |
   +-------------------+
   |Rename...          |
   +-------------------+
   |File Bookmark(s)...|
   +-------------------+
   |New Folder         |
   +-------------------+
   |Properties         |
   +-------------------+

Proposed:
   +-------------------+
   |Open               |
   |Open in New Window |  (bug 25909)
   |Open in New Tab    |  (bug 25909)
   +-------------------+
   |Find a Bookmark... |
   |File Bookmark(s)...|
   |New Folder         |
   +-------------------+
   |Cut                |
   |Copy               |
   |Paste              |
   |Delete             |
   |Rename...          |
   +-------------------+
   |Properties         |
   +-------------------+

Comment 1

[timeless]

fwiw, windows tries to keep clipboard operations separate from delete/rename. 
or in other thoughts, i have 7 seps in my explorer context menu for a folder. 
and you're complaining about 5. you then propose a ui which has 3 and which is 
very very inconsistent w/ any design goals from explorer.

Comment 2

[Hixie (not reading bugmail)]

I could live with a separator between "Paste" and "Delete" -- what I can't live 
with is four separate sections each with only one item.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 4

[Paul Chen]

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged
radar. You can filter out this email by looking for "ironstomachaussie"

Comment 5

[Hixie (not reading bugmail)]

Attachment: Patch: cleans up the menus for bookmarks

Comment 6

[Blake Ross]

Comment on attachment 63169 [details] [diff] [review]
Patch: cleans up the menus for bookmarks

sr=blake

Comment 7

[Doron Rosenberg (IBM)]

Comment on attachment 63169 [details] [diff] [review]
Patch: cleans up the menus for bookmarks

r=doron

Comment 8

[Hixie (not reading bugmail)]

checked in

Comment 9

[Jeremy M. Dolan]

Is what was checked in supposed to match Hixie's proposal? I have file bookmark
in with the CCP ops, no find (which I could do without in the context menu,
frankly), and only open in new window, despite having all the tab browsing
options checked. The bug number you cite for that entry seems to be the wrong one.

Comment 10

[Hixie (not reading bugmail)]

No, what was checked in is not what I originally proposed, it is a slightly
modified one that took into account comments in this bug and on IRC.

The full spec was included in the patch, but, for the record, is as follows:

   +--------------------+
   | Open               |
   | Open In New Window |
   | Open In New Tab    | (not implemented yet)
   | ------------------ |
   | New Folder         |
   | ------------------ |
   | Cut                |
   | Copy               |
   | Paste              |
   | File Bookmark      |
   | ------------------ |
   | Delete             |
   | Rename             |
   | ------------------ |
   | Properties         |
   +--------------------+


> I have file bookmark in with the CCP ops

Yep, they are together for consistency (file and cut-followed-by-paste are
virtually the same thing).


> no find (which I could do without in the context menu, frankly)

It was removed because, as you say, we can do without it in the context menu.
(It makes little sense on the personal toolbar, for instance.)


> and only open in new window, despite having all the tab browsing
> options checked.

That is a separate bug -- bug 117449, bug 116351, bug 113298 or bug 110540
depending on who you ask. Once the logic for that feature is implemented, adding
it to the context menu would be trivial as the patch mentions where to add the 
relevant strings.