If the user right-clicks on a bookmark in a menu, give him/her a context menu like the one in the bookmarks manager.

*** Bug 50503 has been marked as a duplicate of this bug. ***

Reassigning to default component owner since slamm isn't here anymore.

I don't think we currently have anything like context menus for menu items.. would have to see with ben

Might be, so let's implement them :). Adding blocker.

Netscape Nav triage team: this is not a Netscape beta stopper.

is this ment for manage bookmarks or for a normal menu?

Marking nsbeta1- bugs as future to get off the radar.

*** Bug 90604 has been marked as a duplicate of this bug. ***

*** Bug 92258 has been marked as a duplicate of this bug. ***

*** Bug 94686 has been marked as a duplicate of this bug. ***

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

*** Bug 106879 has been marked as a duplicate of this bug. ***

*** Bug 113125 has been marked as a duplicate of this bug. ***

*** Bug 117632 has been marked as a duplicate of this bug. ***

mass reassign of pchen bookmark bugs to ben

*** Bug 119124 has been marked as a duplicate of this bug. ***

*** Bug 121571 has been marked as a duplicate of this bug. ***

*** Bug 133634 has been marked as a duplicate of this bug. ***

*** Bug 136604 has been marked as a duplicate of this bug. ***

*** Bug 137767 has been marked as a duplicate of this bug. ***

*** Bug 140835 has been marked as a duplicate of this bug. ***

I too would love to see context menus for bookmarks. As a minimum they should have the following items: 1.) Open in new tab 2.) Open in new window 3.) Properties 4.) Copy Link location (1.) and (4.) are the ones I REALLY REALLY want. I would also love to see (1.) and (4.) added to the context menus in Bookmark Manager. (1.) This would be a shortcut to constantly having to open a new tab then go to the bookmarks to select the page you want to load. I would estimate that 40% of the time I want a bookmark to open in a new tab and 5% in a new window. (2.) I can live without, but if you have (1.) you pretty much have to have this one also. (3.) This would be really nice so that you wouldn't have to **** around with Bookmark Manager just to update the URL for one broken link. (4.) This would be a shortcut to constantly having to open Bookmark Manager, find the bookmark, go to its Properties, then copy the URL onto the clipboard so that you can paste it elsewhere - particularly when you are trying to e-mail a link or put it into a newsgroup message. This is about a thrice daily task for me.

Suggesting the following context menu appearance: |-----------------| Open Bookmark <-- default left-click action; should be BOLD Open in New Tab Open in New Window --Separator-- Copy Link Location --Separator-- Properties |-----------------| Note that the default action when left-clicking should be bold, to indicate that that's what is going to happen if the user just left-clicks.

#22 , #23 Urm, I belive the context menu of a bookmark item with*in* a bookmark menu should be consistent with the context menu of a bookmark item that's directly on the personal toolbar. Which is |-----------------| Open [Bookmark] <-- default left-click action; should be BOLD Open in New Window --Separator-- New Folder... . . . And so on, weird cut copy paste commands that imho shouldn't be there (at least not on first thought). Then a "File Bookmark..." command which doesn't belong here at all (to create a new bookmark is entirely out of context of handling a current one). Then Delete and Rename (these do make sense). Now the same: --Separator-- Properties |-----------------| So, no Open in New Tab yet, yet I believe it *should* be there (CMIIW, but I believe a bug is filed about that already). Same goes for Copy link location and maybe Copy (be more specific - *what* does that copy! the name, i guess). But "cut" and "paste"? Beyond me how they make sense here. Aside from this, last word still isn't spoke on the justificated "may a menu item or even a submenu have its own context menu?" issue.

Re: #24 As to your pondering whether it is appropriate for menu items or subitems should have context menus: 1.) Yes ! Always ! Even if it is a just a single item like "What is this?" that takes the user to a relevant location in the help file. This would beat the heck out of forcing the user to use the inevitably non-intuitive help file indexes and searches that always circle around what you are looking for but seldom take you right where you need to go. 2.) Even if you disagree with that, stop thinking of bookmarks as menu items. The are objects that exist entirely independently of the menu systems and the menu system - at least as it pertains to bookmarks - should exist for the purpose of using and manipulating the bookmark objects. And how do you put a bookmark on your personal toolbar ? Because of something else in comment #24 I wanted to take a look at the context menu for a bookmark on a toolbar, but ( with RC3 on NT4 ) when I drap the bookmark icon from the address bar to my personal toolbar nothing happens even though the help file says that is what I should be doing.

Re: #24 As to your pondering whether it is appropriate for menu items or subitems should have context menus: 1.) Yes ! Always ! Even if it is a just a single item like "What is this?" that takes the user to a relevant location in the help file. This would beat the heck out of forcing the user to use the inevitably non-intuitive help file indexes and searches that always circle around what you are looking for but seldom take you right where you need to go. 2.) Even if you disagree with that, stop thinking of bookmarks as menu items. The are objects that exist entirely independently of the menu systems and the menu system - at least as it pertains to bookmarks - should exist for the purpose of using and manipulating the bookmark objects. And how do you put a bookmark on your personal toolbar ? Because of something else in comment #24 I wanted to take a look at the context menu for a bookmark on a toolbar, but ( with RC3 on NT4 ) when I drap the bookmark icon from the address bar to my personal toolbar nothing happens even though the help file says that is what I should be doing.

Re: comment #25 > As to your pondering whether it is appropriate for menu items or subitems should have context menus: > 1.) Yes ! Always ! In most cases, it does not make sense. And it seems very confusing to me, dependant on the looks of the menus on the target platform (yes, we have a platform-independent look in most cases, but not for instance with classic mode activated, and additionally *never* on Mac OS or Mac OS X concerning menus). Let's say you go to menu I || submenu Ia || subsubmenu Ia1 || subsubsubmenu Ia1i, and there, you want to edit something. So you right-click. That leaves us with five menus open at once: the menu, the submenu, the subsubmenu, the subsubsubmenu, *and* the contextual menu *of* the subsubsubmnenu Ia1i. Confused yet? I bet most people will be. > Even if it is a just a single item like "What is this?" that takes the user to a relevant location in the help file. That's not a bad idea per se, but should be done in another way; for example, Microsoft used to have a help menu item that gave you a help cursor (a pointer with a question mark attached to itself). You could then navigate to any toolbar item, menu item, or whatever, click, and you would get an extended tooltip (or, on Mac OS, a help balloon). > This would beat the heck out of forcing the user to use the inevitably non-intuitive help file indexes and searches that always circle around what you are looking for but seldom take you right where you need to go. Yeah, okay, but above stuff does the same, and we're really at another bug here. I do not disagree that a context menu for a menu item *were* a nice thing to have. Unfortunately, it doesn't fit in with current GUI concepts for menu bars, menu items and menus. > 2.) Even if you disagree with that, stop thinking of bookmarks as menu items. Hmm... the xul source clearly states they *are*. And the summary of this bug does too. So unless you change both, why should I? > The are objects that exist entirely independently of the menu systems and the menu system ...and yet they are rendering dynamically into it. Just like history items, or "last few opened documents" items in office apps. > - at least as it pertains to bookmarks - should exist for the purpose of using and manipulating the bookmark objects. The sole purpose of the menu system in current typical GUIs is to ease giving the computer commands. You no longer write "del *.*" in a terminal, but instead click "Edit", "Select All", "File", "Delete", "OK" (which sounds a lot more inconvenient, and indeed *is* for mass operations, but usually not for single operations). The menu system, in its current stage, cannot give you the ability to edit the menu itself; an external toolkit is needed, such as Microsofts GUI for editing menus (as seen on several MS Office apps). The workaround is to add menu items to edit other menu items. Which doesn't only *sound* awkward, but actually *is*. The two ways to accomplish this, namely a) to add a submenu to each "editable" menu item with the edit options (can anyone say "overly complex menu structure"?) b) to add a context menu to each "editable" menu item with the edit options (see top of this comment) , are both bad ideas. I also vote against a middle-click way (let's say you middle-click the bookmark menu item and then get a dialog which gives you editing possibilities) as this is also an artificial way to expand the menu system. > And how do you put a bookmark on your personal toolbar? Drag and drop? > Because of something else in comment #24 I wanted to take a look at the context menu for a bookmark on a toolbar, but ( with RC3 on NT4 ) when I drap the bookmark icon from the address bar to my personal toolbar nothing happens even though the help file says that is what I should be doing. It's what I've always been doing, and it seems to work fine; since several weeks even with sub-folders (that's drag-and-drop within menus, which isn't that good an idea either, though!).

*** Bug 149693 has been marked as a duplicate of this bug. ***

*** Bug 149800 has been marked as a duplicate of this bug. ***

Seems you should be able to "Open in Tab" and be able to middle/mouse click a bookmark to open in a tab. The menu is fixed on the personal toolbar, but is missing these options.

Can you still drag and drop a url into a folder on the personal toolbar? I cant seem to do it on this 1.0, I know it was working on the nightly trunk.

Re: Comment #31 From Brook Harty 2002-06-07 01:52 > Can you still drag and drop a url into a folder on the personal toolbar? WFM on 2002-06-05-19, Trunk, Win32.

*** Bug 151331 has been marked as a duplicate of this bug. ***

*** Bug 153616 has been marked as a duplicate of this bug. ***

*** Bug 158724 has been marked as a duplicate of this bug. ***

Add a "Sort By Name" to the Bookmark context menu.

Hao Lian, that's not what this bug is about. If you want that functionality, you should submit a RFE for that and make it depend on this bug. I don't know if a RFE has been filed already?

There is a discussion going on in bug 176880 about if that one is a duplicate. Reason: this bug's description and comments are not very clear on if it refers a) only to the bookmarks in the "Bookmarks" menu in the Personal Toolbar (next to the "Home" button) or b) to the bookmarks in Personal Toolbar folders (right to the "Bookmarks" folder) or c) to both. Source of the confusion seems to be the wording "bookmark in a menu" and "a bookmark menu", which sounds like "THE bookmarks menu", but also seems to indicate that there are several such menus. Ben, Chucker, can you help? Thanks...

Answer: "c" (as minimum) IMO Let's not forget that bookmarks and bookmark folders (no matter where they appear in the UI) are user-created and managed - as opposed to regular menus, which are "managed" by Mozilla. Therefore, *any* bookmark folder should be treated more like a directory than a menu. Let us learn from MS Windows 98, where it became possible to edit *and* drag & drop shortcuts anywhere within the START menu. That was a *huge* improvement to the configurability of MS Windows's Start button. Mozilla's bookmarks and bookmark folders should have a context menu *and* allow drag & drop no matter where the bookmarks and bookmark folders appear in the UI (i.e., Sidebar, Menu:"Bookmarks", Personal Toolbar "Bookmarks" folder, and Personal Toolbar user-created folders for bookmarks). Although Bookmarks folders look like menus (and programmatically, they may be menus), but to the user they are *his* bookmarks *folders* (more like directories and not like menus). Proposed rule of thumb: When there is a conflict between what seems technically logical/correct/easy and what the user wants/expects, then the user's wants/needs are to be preferred. The user could (nor should he) care less about what goes on behind the scene.

Andreas, as far as I can tell, this bug is about c) (both). It makes no sense for me to implement this to either, but disallow it for the other. As to the status, I'm still arguing with myself on whether or not any menu item may have a context menu... The same applies to bug 19437. Drag-and-drop of non-static elements such as drop-down menu items sounds complicated to me As bug 64324 is now a dupe of bug 172276, updating dependencies.

Re: Comment #39 From Peter Lairo 2002-10-30 02:48 > Let us learn from MS Windows 98, From a system that had - at that time - the most bloated user interface, crashed most often, and added nearly no real value over Windows 95? I'd rather not. > where it became possible to edit *and* drag & > drop shortcuts anywhere within the START menu. That was a *huge* improvement > to the configurability of MS Windows's Start button. It was also a usability mess. Ever third time you try drag&drop in the start menu, something unexpected will happen - like an app (which you wanted to drag elsewhere) suddenly launching, etc. > Mozilla's bookmarks and bookmark folders should have a context menu *and* > allow drag & drop no matter where the bookmarks and bookmark folders appear > in the UI (i.e., Sidebar, Menu:"Bookmarks", Personal Toolbar "Bookmarks" > folder, and Personal Toolbar user-created folders for bookmarks). Drag&Drop is bug 19437, which depends on this one. > Although Bookmarks folders look like menus (and programmatically, they may be > menus), but to the user they are *his* bookmarks *folders* (more like > directories and not like menus). I'd prefer the following: each bookmarks menu ends with a seperator and then the menu item "Edit..." that opens that bookmark folder. *There*, you already *can* do drag&drop and editing. You *do* already have context menus. > Proposed rule of thumb: > When there is a conflict between what seems technically logical/correct/easy > and what the user wants/expects, then the user's wants/needs are to be > preferred. > The user could (nor should he) care less about what goes on behind the scene. This is not a technical problem, but rather the problem: does the average user really want to be confused by menus that can be edited inline, and have context menus? If you excuse the analogy: (almost) every menu item having a context menu is like every book having several magazines with related information in it (or vice versa).

> the problem: does the average user really want to be confused by > menus that can be edited inline, and have context menus? I'm probably no average user, so I can only tell for sure that it would be very handy for me to e.g. delete and rename bookmarks there by just right-clicking. I personally do not think context menus would confuse "average users" more in Personal Toolbar folders than they do in "regular" Personal Toolbar bookmarks. Their purpose is identical and very obvious from the entries of the context menu. And they look like folders, not like menus, no matter how they are designed internally. So context menus should not be confusing there IMHO. But its not my decision...

Re: Comment #42 From Andreas Kunz 2002-10-30 03:44 > I'm probably no average user I'd say that anyone who postes to BugZilla can't be considered an average user. > Their purpose is identical and very obvious from the entries of the context > menu. That's true. > And they look like folders, not like menus, no matter how they are designed > internally. So context menus should not be confusing there IMHO. > But its not my decision... I think you're confusing things. This bug is about implementing context menus for a certain kind of menu items, namely bookmarks that reside in bookmark folders. For example, if you have a folder "foo" in your Personal Toolbar Folder, which contains the bookmarks "bar", "baz" and "boo", and the folder "bum" which contains the bookmark "nada", then this bug applies to "bar", "baz", "boo", "bum" and "nada", but not to "foo". All 5 of those are supposed to have their own context menu. Note that *all* of them are (if we leave the Bookmarks Manager aside right now) only accessible from within *menus*. So you click on "foo", which opens a menu containing "bar" amongst others. And now you're supposed to right-click "bar". The problem is that this will open another menu (the context menu), while leaving the other one open. The question is if this is really convenient.

I am probably considered more or less an average user, and personally I can't relate how frustrating it is NOT to have that context menu in bookmarks. From a usability standpoint, it is a huge hassle to be forced to go to the Manage Bookmarks menu instead of simply being able to right click and rename, sort bookmarks by name, and so forth. It becomes MORE complicated for me as it is at present. I both agree and encourage that the bookmarks menu (both on the personal toolbar and the menu item) should be able to be drag-and-drop managed AND have a context menu. These features may have been bulky in Windows 98, but in newer versions of Windows they are a great help.

RE Comment #43: It is (luckily) currently possible to rename/delete the folder "foo" too (with context menu).

Re: Comment #43 > I think you're confusing things. No, I think I only did not express myself clearly: all those "bar", "baz" etc. things are exactly, what I meant and how I understand this bug. So we agree about that. What I wanted to express, was my opinion that users - especially not-so-geeky ones - perceive the folders on the Personal Toolbar more as "folders that function like menus" than as menus (what they are technically). And that therefore context menus for their items should not be too confusing.

> This bug is about implementing context menus for a certain kind of menu > items,namely bookmarks that reside in bookmark folders. Let's clarify that statement. This bug is about inline context menus for editing the properties of bookmarks. Anything that can be renamed or have its URL changed (at least that - other functions may/may not be added later) from the Bookmark Manager should able to be so edited inline. I also don't think we should be carried away by throwing the kitchen sink at this bug. If we get a handful of basic context menu functions, this bug can be satisfied and other enhancements added to future bugs dealing with the (then) already existing context menus for bookmarks. In fact, the easiest way of getting code into this thing, is if we simply re-use the existing code already in the Bookmark Manager. That way, if we right-click on a bookmark item inline it will behave exactly the same as if we'd right-clicked on the same bookmark item from within the Bookmark Manager. There's no need to reinvent the wheel here. Things that currently don't exist in the Bookmark Manager context menus, wouldn't be in the inline context menus - at least right away.

How easy it is depends on the implementation. Put in words it may sound complicated ("you got menus inside menus inside menus omg!"), but in practice it actually is quite easy and usable if implemented in a non-annoying way. I agree with comment #44. Say you are browsing your bookmarks menu and see one with a wrong name or in a wrong folder. The first thing one tries to do is alter it on the spot via drag and drop, a context menu or whatever other immediate method. Having to remember to open a _separate window_ and then navigate all the way back to alter one bookmark is very annoying and distracting. Is feels like forgetting your office keys at home. Now if users browsed their bookmarks normally with the Bookmark Manager, that would be different, because they would not have to make the mental separation of tasks (browsing bookmarks and editing bookmarks), since all the options are right there. From what I've observed people mostly use what they have in plain sight (Bookmarks Menu) and not elements that require additional steps to access (Sidebar & Bookmark Manager)

What are the odds of having a 'Sort by Name' option in such a context menu? Would that be considered as one of these 'way-too-much' categories? I know for myself this would be an incredible convenience, myself being an organization freak. I absolutely HATE everything being chronilogically organized.

> What are the odds of having a 'Sort by Name' option in such a context menu? Since I wouldn't be writing the code for this, I can't say. I don't really know what the easiest approach is here. But shouldn't the bookmarks in the dropdown menus appear in the same order as they do in the Bookmark Manager? If not, I'd find it very confusing to have them presented in different ways depending on where I was... (And to answer the questions specifically, I would assume that whatever sorting methods are available from within the BM could be hooked up to the context menus without too much difficulty - or there could simply be a link to the BM in the context menus, from where you could do the same thing.)

Re: Comment #45 From Peter Lairo 2002-10-30 05:52 > RE Comment #43: It is (luckily) currently possible to rename/delete the folder > "foo" too (with context menu). I know. But not to folder "bum"! Andreas, Jason: I believe you misunderstand the real problem. Obviously, a normal bookmark or bookmark folder should have exactly the same context menu as in the Bookmarks Manager. A non-top-level bookmark or bookmark folder, though, already *is* in a menu *itself*. So its context menu would be a menu *on top of* another menu. Which isn't only quite ugly, and may not only not work right with many Operating Systems, no, it's also very, very confusing. This (contextual menus for menu items) has been implemented a while ago through the Phoenix project, but I really hope that its actual usage will be considered every time someone believes it's needed.

> A non-top-level bookmark or bookmark folder, though, > already *is* in a menu *itself*. What I'm trying to say is that this bug shouldn't be concerning itself with non-bookmark menu items. Anything that is a bookmark item should behave the same as it does in the Bookmark Manager; anything that isn't, should be addressed in a related bug but not in this one specifically. Perhaps there's also some additional confusion. I don't use the personal toolbar or the sidebar (too much clutter for me). So when I look at this bug, I'm looking at it from the perspective of what you see when you click on the Bookmarks file menu... This bug should be addressing all 3 scenarios - but is there not some minimal common ground for discussion that won't cause such confusion?

I don't really find that 'menu for a menu' concept all that confusing. I agree with the comments that this would be more useful than not, and the bookmarks menu should be seen more as a directory structure than a menu. Not to mention the comment that people expect to change something on the fly, instead of digging through other menus and interfaces to get there. These comments are words of gold in this issue. A context menu with at least some basic options (Cut, Copy, Rename, Delete, Refresh [for offline viewing], Properties, and Sort by Name [which I propose should apply to BOTH the Bookmarks drop-down and the Bookmarks Manager], etc.) IS necessary *because* of the usability issues, not something that conflicts with them. It is very well implemented in other browsers *cough* IE *cough* and could be well implemented in Mozilla.

guys: please stop using bugzilla as a newsgroup.

Re: comment #53 - "A context menu with at least some basic options (Cut, Copy, Rename, Delete, Refresh [for offline viewing], Properties, and Sort by Name " And above all "Open in new Tab". Even Multizilla doesn't offer that kind of basic functionality yet.

<OT> > guys: please stop using bugzilla as a newsgroup. If you'd like to submit a patch or contribute to the discussion in a meaningful way (one that clarifies the bug) then please do so. We are not "arguing senselessly" here in such a manner as just to create noise, but are trying to clarify exactly what this bug is after such that it can be addressed properly. So far, I have seen no off topic posts. Except for yours and this response, which I'll apologise for ahead of time. </OT>

*** Bug 177889 has been marked as a duplicate of this bug. ***

The 'menu for a menu' concept is not confusing, it's GENIAL !! Infact, i consider this to be one of the missing moz feature that will surely block IE users to switch to moz as a general browser. If i want to rename a bookmark, i'm actually forced to drag&drop it to personal toolbar, rename there with context menu, and drag&drop it again to the place it come from.. it's absurd from an usability point of view. (locate it using bookmark manager would require a much more number of clicks anyway) I would invite users here to discuss *HOW* to implement this feature, not to argue if this feature is good or not, as it is evident that any browser without it would be considered outdated from the beginning. IMHO, basic functions to be available in the bookmarks context menu would be just the same of what already is implemented in context menu for first level items in personal toolbar. The only difference is the "rename" function, it's dumb to just call the "properties" function, much more better a simple textbox where to edit the name without being distracted by other details. Any hopes for 1.3a ???

*** Bug 178315 has been marked as a duplicate of this bug. ***

My two cents. About consistency of possible UI in possible implementation:) - tree and actions together. As example - look at http://www.fi.tartu.ee/~sergei_d/contextmenu.gif - it is context menu for (file system) graphical shell. So it shows simultaneously subfolders at top, and possible action below. If we are at bottom items, it may show only actions. It seems that this is quite applicable in our case, question is where should be actions, and where - subtree (below or above). Also, idea is if you hold and move to subfolder - it behaves as it is now. If ypu click (or in some OS-es) release button on subfolder - it may open it in bookmarks manager

I'm not sure what's going on with this bug. I've seen a dozen different "ideas" tossed around, and all I want is a method of DELETING and sorting bookmarks (favorites) which is similar in style to Internet Explorer. I want to be able to click on bookmarks, scroll down and if I see a bookmark I don't want anymore, I want to be able to right-click and select DELETE. Also, if I wish to sort bookmarks into folders, it would be nice to grab one, and physically drag it to the folder it should go in or grab it and move it up or down in the list in that folder. This is much faster and more intuitive than going into some bookmark manager and finding bookmarks, deleting and sorting them each time you make a decision about what to do with one. I am constantly bookmarking web pages, sorting them by subject into folders and deleting old links and/or subjects which are no longer necessary. The Current Mozilla system is not adequate for easy, fast editing, deletion, renaming, and sorting of bookmarks on the fly. If I have to visit each site, make a list of which ones are outdated or unneccessary, then go into a bookmark manager and find all of those links to delete them (or sort them if they are necessary, but out of place), that could take all day. It would be nice to click on a bookmark, view the page, then go back to the bookmark and select delete, edit, rename, or just drag it to another folder. I don't know how difficult that would be to impliment, but it is a necessity for how I manage my bookmarks (favorites) in Internet Explorer and is a major reason I don't use Mozilla as my primary browser.

I'm absolutely of the same opinion. This is a major blocking usability issue for me also.

*** Bug 183009 has been marked as a duplicate of this bug. ***

Please, extend the context menu to *all* bookmark inside the dropdown folder (and subfolders as well) of personal toolbar, bookmark handling seem mutilated to me without this simple feature. There is no reason for users to perceive differences between the bookmark tree in sidebar and bookmark menu/tree in personal bookmark.

In response to comment #61, I am totally in agreement. While something fancy would be nice down the road, I just want to be able to delete my bookmarks when scanning them without having to go into the manager just to such a simple task. I personally don't even care if this means the use of a key-binding, like <DELETE> when hoving over the bookmark...just give us SOMETHING! Dragging and dropping I believe that most first time users would expect, but at least get the delete in there so that people don't think this is a broken aspect of mozilla.

*** Bug 186068 has been marked as a duplicate of this bug. ***

is this a dupe of bug 19437?

No.

Any news about this enhancement progress ? I strongly suggest to nominate it for the next milestone. It has 34 votes so far and the dipendence from bug 172276 no longer exist. IE6 have menu over menus since ages, and i admit they are dramaticaly useful. For coherence, i would like to see such contextual menu everywhere a bookmark can exist on UI interface (menu/sidebar/pers.toolbar/etc.etc.)

*** Bug 189487 has been marked as a duplicate of this bug. ***

What is the status of this enhancement? My wife, recently used Mozilla for the first time, and absolutely loves tabs. But she was amazed that the context menu for bookmarks in the Toolbar contains "Open in New Window", but not "Open in New Tab". And I am constantly annoyed that there is no context menu for bookmarks within a folder on the bookmark toolbar. Tabs are a great feature. Mozilla should make them as easy to use as possible, and adding a proper context menu with "Open in New Tab" goes a long way. I consider proper context menus for bookmarks, whether they be in the manager window, in the main menu, or in the toolbar menu, to be very important. Regardless of your ideological or theoretical stance on bookmarks being objects, menu items, or whatever, the gui should help users, and at the very least present choices they expect to have. The context menu for a bookmark in all three locations should be very similar to what is currently in the bookmark manager, with one addition (Open in New Tab): Open (bold) Open in New Tab Open in New Window --Separator-- New Folder --Separator-- Cut Copy Paste File Bookmark(s)... --Separator-- Delete Rename --Separator-- Properties

Please do not spam the list with questions about things like asking about the status. If the bug is fixed, then it will be marked as such. Suggestions have already been made, but new ideas are welcome.

I don't think my comment was spam. I've read through many of the comments, and I consider my input at least as useful as many of them.

*** Bug 193899 has been marked as a duplicate of this bug. ***

I would also like to see context menus for items in expanded Personal Toolbar folders and not just in the Bookmark menu.

I would like to see context menus for items in expanded Personal Toolbar folders and not just in the Bookmark menu. Nomination for 1.3 final ???????????

*** Bug 198674 has been marked as a duplicate of this bug. ***

*** Bug 203958 has been marked as a duplicate of this bug. ***

On the off-chance that this ever gets done, I would like to see an "Update" option on the context menu. When this option is selected, the properties for the selected bookmark would be displayed with the old URL replaced with URL of the current tab, at which point the user could "Cancel" the change, "OK" the change, or manually edit the properties of the bookmark.

*** Bug 204858 has been marked as a duplicate of this bug. ***

*** Bug 206288 has been marked as a duplicate of this bug. ***

It's countless how many times i pressed the right mouse button on a bookmark folder to rename the entry... ... and get frustrated ...

You should read this: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Thank you for volunteering to work on so many bugs, let's start with this one.

*** Bug 116531 has been marked as a duplicate of this bug. ***

I am a sub average user of the browser. I have looked at the Linux mozilla version 2.4 and current milestone of firebird and find the thread of this bug addresses one very useful enhancement. If a context menu is added to the bookmarks browsing, it should contain one additional bookmark management action..."add bookmark before"..."add bookmark after". As others noted, having to use the bookmark manager to change a bookmark's "properties" is annoying. Similarly, adding a URL to your bookmarks and then having to use the bookmark manager to organize that bookmark into your bookmark hierchary is diversionary. An additional entry in the bookmark browser (for each folder and subfolder) that adds a bookmark to the current URL, in that folder, is a minimal organizational tool that KDE's konqueror browser has implemented.

*** Bug 214934 has been marked as a duplicate of this bug. ***

*** Bug 218107 has been marked as a duplicate of this bug. ***

I want the ability to open the properties menu with a right click too. I really USE the bookmarks and have a fairly comprehensive set. As it is now, the only thing shown either from Bookmarks on the main menu or Bookmarks on the Personal Tool Bar is the title given to the URL - which could be damn near anything, considering the ill use by web site designers of the meta tags. Right Click menu: 1. Edit properties 2. Open in new tab 3. Open in new window 4. Create new folder 5. Copy to clipboard. As it is now, any user who tries to copy a bookmark URL to the clipboard from the menu by hitting Control-C (standard windows key), jumps to the first bookmark starting with C! Not a good choice. Please don't make me go to the Bookmark Manager to get things done. I want to know the name, URL, description and key field from the context menu, otherwise, the only way bookmarks are useable in Mozilla is to keep the Bookmark Manager open all the time while surfing. Gahhhhhhh!

I see.. this bug need HUGE massive voting to be taken into any consideration. We are on the right track with 50+ votes, but we need much more. I personally consider this the most annoying bug (or missing feature) BY FAR. My email was not intended for pollute this list, but i notice now that the "assigned to" field contains my email address ... am i wrong ? I never intended to assign this bug to myself, i even don't know if i have right to assign anything to anyone else.. Please, delete me from "assigned to" and assign to another developer, as far as i'm only an enthusiast supporter of mozilla and never involved in any coding or bugfixing project. I've selected "reassign to owner and QA" ... i hope i have not messed up something. Thank you!

Paolo, timeless assigned this bug to you, implying that you should contribute the code, if you yell to have something implemented. Otherwise, you are demanding others to work for you for free. You are violating bugzilla etiquette, as pointed out by comment 83. And asking random other people to vote for your favourite bug is IMHO abusing the system.

I apologize, Assigning to myself has been a typo mistake i was not aware of until today. Sorry for netiquette violation.

*** Bug 222611 has been marked as a duplicate of this bug. ***

*** Bug 234798 has been marked as a duplicate of this bug. ***

*** Bug 176880 has been marked as a duplicate of this bug. ***

Ok, this is getting so damn many duplicates all having almost the same subject. And even I - being well aware of this bug - had to search a few minutes to find it! => adjusting summary

This bug is not (primarily) about the personal toolbar, but the real menu

(In reply to comment #97) > This bug is not (primarily) about the personal toolbar, but the real menu Ben, 1.5 years ago, in comment #38 I asked you what this bug exactly is about, because the description was not clear or detailled at all ("bookmarks menus", "a menu"). Since then, almost dozens of bugs about the personal toolbar have been marked as dupes of this one and most of the other comments indicate the PT is meant, as well. This all without any intervention from you; that's what I call a weak bug "reportership", if there is a word like this... So as it seems, there is no bug report for context menus for bookmarks in PT folders, right? So should somebody file a new bug for that?

Your question got lost in all the uninteresting comments. I think the bug is pretty clear as stated. The primary menu is the menubar and its menus, and the bookmarks menu there is what this bug is primarily about. However, it makes sense to do the same for all the menus in the Personal Toolbar, and it's probably easy to do so, so I don't see why this bug shouldn't cover that as well. And the initial description is worded just so.

> I don't see why this bug shouldn't cover that as well So would you mind re-adding "personal toolbar" to the summary? Most of the dupes include it.

done [OT] we should have better searching. summaries should be concise, so can't include all keywords

(In reply to comment #100) > > I don't see why this bug shouldn't cover that as well > > So would you mind re-adding "personal toolbar" to the summary? Most of the dupes > include it. How about DROPPING "personal toolbar" completely. This bug is about the bookmarks menu. Nothing whatsoever to do with the personal toolbar. The fact the "most of the dupes include it" merely shows that whoever is marking them as dupes of this bug doesn't know what the heck he is doing. Unless someone can provide reason to believe that the code needed to add context menus to the bookmarks menu would also do the same thing for the personal toolbar, then the personal toolbar issue should be an entirely separate bug. However, my understanding is that it would take two separate coding efforts to add context menus to both the bookmarks menu and the personal toolbar - hence these should be separate bugs. As well, this bug has rapidly decreased in importance since the context menus ARE there in FireBird - for both the bookmarks menu and the bookmarks toolbar. Since the long term plan is to drop Mozilla completely and focus on FireBird and TBird, perhaps it is time to simply mark this bug as "WONTFIX".

(In reply to comment #102) > This bug is about the bookmarks menu. Nothing whatsoever to > do with the personal toolbar. This is Ben Bucksch's bug, not yours. He decided. Almost every implementation of a feature consists in several parts, so this is not neccessarily two separate bugs. The main problem with implementing this is if there can and should be menus for menus. And this makes both aspects similar enough to handle them in one bug report. > Since the long term plan is > to drop Mozilla completely and focus on FireBird and TBird, > perhaps it is time to simply mark this bug as "WONTFIX". Nobody is speaking about dropping it completely, as long as there are volunteers who like to work on it, the Suite will live. This is a Mozilla Suite bug, having nothing to do with Firefox. You could as well say "let's wontfix all the tens of thousands Suite bugs" - because it is not main focus of Mozilla Foundation anymore...

*** Bug 281229 has been marked as a duplicate of this bug. ***

This is already implemented in Firefox, anybody can steal it from there legally (GPL)! Please do it, I like Seamonkey more than these stand-alone crippled thingies... Mathis from Hannover, Germany

(In reply to comment #105) > This is already implemented in Firefox, anybody can steal it from there legally > (GPL)! yup - nobody's got it. who's first?

(In reply to comment #105) > This is already implemented in Firefox, anybody can steal ... Hmm the Firefox implementation on OSX doesn't work correctly. it opens the bookmark in current window even when you try to open it in a new tab. And it also leaves the popup menu hanging.

(In reply to comment #106) > (In reply to comment #105) > > This is already implemented in Firefox, anybody can steal it from there legally > > (GPL)! > > yup - nobody's got it. > who's first? > Setting context= or contextmenu= on the <menupopup> using DOMI doesn't seem to work for me :(

OS Name - Microsoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600 OS Manufacturer Microsoft Corporation System Name NOMAN_V System Manufacturer TOSHIBA System Model Satellite A70 System Type X86-based PC Processor x86 Family 15 Model 4 Stepping 1 GenuineIntel ~3066 Mhz Processor x86 Family 15 Model 4 Stepping 1 GenuineIntel ~3066 Mhz BIOS Version/Date TOSHIBA V1.30, 09/10/04 SMBIOS Version 2.31 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 First, I'm not a Mozilla programmer, but I have always been a Mozilla user (first Netscape until bought by AOL.) From the main menu Bookmarks: I'm used to opening tabs with a right click and when I'm in my Bookmarks right-clicking create a small square radio box under my cursor. Clicking it does nothing. Click anywhere else but the button and the dropdown dissappears. When I re-enter the Bookmarks, clicking on the sub-directory does nothing, while one-click items will still be accessable. This condition remains until I close the program and re-open. I can't say I've really seen this bug mentioned, but this is a long thread I see similar requests for context menus in the main Bookmarks, which would be a nice addition & I'll vote for it - in particular 'Open in a New Tab.' It works from the customized personal toolbar just fine. One other thing would be a function be where Bookmarks sub-folders have the 'Open in Tabs' where those links no longer working could be moved to a 'Need to be Fixed' folder and later deleted. Thanks for a great product,

bug 116531 is a dup so no longer dependent In reply to comment #108) >... > Setting context= or contextmenu= on the <menupopup> using DOMI doesn't seem to > work for me :( so...something else is blocking / isn't working?

(In reply to comment #110) > bug 116531 is a dup so no longer dependent > > In reply to comment #108) > >... > > Setting context= or contextmenu= on the <menupopup> using DOMI doesn't seem to > > work for me :( > > so...something else is blocking / isn't working? > I have no idea.

This patch is derived from the one in Bug 19437 comment 50. In addition to adding context menus to the Bookmarks menu, it also adds them to the Bookmarks button on the Personal Toolbar, bookmark subfolders on the PTB, and the chevron list on the PTB. I've only tested this on Windows so far, so it still needs testing on other platforms.

Comment on attachment 230719 [details] [diff] [review] Context menu patch Tested and working under Linux. Requesting review.

Comment on attachment 230719 [details] [diff] [review] Context menu patch >+ <menuitem key="addBookmarkKb" command="Browser:AddBookmark" context=""/> >+ <menuitem key="addBookmarkAsKb" command="Browser:AddBookmarkAs" context=""/> >+ <menuitem command="Browser:AddGroupmarkAs" context=""/> >+ <menuitem key="manBookmarkKb" command="Browser:ManageBookmark" context=""/> > <menuseparator/> >+ <menuitem command="Browser:AddBookmark" context=""/> >+ <menuitem command="Browser:AddBookmarkAs" context=""/> >+ <menuitem command="Browser:AddGroupmarkAs" context=""/> >+ <menuitem command="Browser:ManageBookmark" context=""/> > <menuseparator id="lastStaticSeparator"/> I don't like all these context attributes. Perhaps you could find a way to cancel the context menu if it turns out you clicked on one of these items? Also you forgot to prevent the context menu on those separators. >+ BookmarksMenu.closeAllBookmarks(document.getElementById("BookmarksMenu").firstChild); >+ BookmarksMenu.closeAllBookmarks(document.getElementById("bookmarks-button").firstChild); >+ BookmarksMenu.closeAllBookmarks(document.getElementById("bookmarks-chevron").firstChild); >+ BookmarksMenu.closeAllBookmarks(document.getElementById("bookmarks-ptf").firstChild); I tried this on Linux and it didn't seem to need this, which is good because I don't like it! Perhaps it's a difference between the trunk and the branch?

(In reply to comment #114) > I don't like all these context attributes. Perhaps you could find a way to > cancel the context menu if it turns out you clicked on one of these items? Also > you forgot to prevent the context menu on those separators. Both have been fixed in this updated patch. > I tried this on Linux and it didn't seem to need this, which is good because I > don't like it! Perhaps it's a difference between the trunk and the branch? The version that I have been doing most of my testing on (1.8 branch on Windows) has the annoying habit of leaving the bookmark menus selected after a context menu is opened. I replaced that code with some cleaner code borrowed from Firefox.

(In reply to comment #115) > The version that I have been doing most of my testing on (1.8 branch on > Windows) has the annoying habit of leaving the bookmark menus selected after a > context menu is opened. I replaced that code with some cleaner code borrowed > from Firefox. Oops, I meant "had," not "has." In other words, that code was necessary to properly deselect the bookmark menus, at least on the 1.8 branch on Windows. I replaced it with cleaner code, though.

Comment on attachment 231042 [details] [diff] [review] Context menu patch v2 Thanks for those changes, this patch is looking really good now. >+ BookmarksMenuDNDObserver.mCurrentDragOverTarget = null; >+ BookmarksMenuDNDObserver.onDragCloseTarget(); Nit: these are tabs! they shouldn't be ;-) > this._observers = [ > document.getElementById("bookmarks-ptf"), >- document.getElementById("BookmarksMenu").parentNode, >+ document.getElementById("BookmarksMenu").firstChild, > document.getElementById("bookmarks-chevron").parentNode, > document.getElementById("PersonalToolbar") > ] Is this change necessary? I don't want drag-n-drop to stop working!

(In reply to comment #117) > Nit: these are tabs! they shouldn't be ;-) Oops! Fixed in the newest patch. > Is this change necessary? I don't want drag-n-drop to stop working! That line was changed as part of the fix for Firefox Bug 210910, which I encountered when adding context menus to the Bookmarks menu. The problem is that the onDragCloseMenu function looks for the "open" attribute, but menubar menus such as BookmarksMenu don't have one. I've done some additional testing, and it does not appear to affect the behavior of drag-n-drop.

Here's a better solution to the problem. This patch accomplishes the same goal as the previous one without modifying any of the DND code.

Comment on attachment 231702 [details] [diff] [review] Context menu patch v3 >@@ -61,6 +64,9 @@ > { > if (content) > content.focus(); >+ BookmarksMenuDNDObserver.mCurrentDragOverTarget = null; >+ BookmarksMenuDNDObserver.onDragCloseTarget(); >+ BookmarksMenuDNDObserver.onDragCloseMenu(document.getElementById("BookmarksMenu").firstChild); > BookmarksMenuDNDObserver.onDragRemoveFeedBack(document.popupNode); // needed on cancel > aEvent.target.removeEventListener("mousemove", BookmarksMenuController.onMouseMove, false); > }, As per bug 347144 this part will become unnecessary. r+sr=me on the rest.

(In reply to comment #120) > As per bug 347144 this part will become unnecessary. r+sr=me on the rest. Thanks for the review. Now that Bug 347144 is fixed, could this be checked in on the trunk as well?

Fix checked in.

Comment on attachment 231702 [details] [diff] [review] Context menu patch v3 'approval-seamonkey1.1a =?': Wanted 1.1 feature.

Comment on attachment 231702 [details] [diff] [review] Context menu patch v3 a=me for SM1.1a assuming bug 347144 gets its a-1.8.1

Fix checked in to the branch.

Verified FIXED on SeaMonkey trunk with build 2006-09-10-08 using Windows XP. I checked the Personal Toolbar, the Bookmarks top-level menu, as well as the Manage Bookmarks sub-menu items.

*** Bug 19437 has been marked as a duplicate of this bug. ***

This caused bug 353446; please take a look when you get a chance? Thanks!

*** Bug 360019 has been marked as a duplicate of this bug. ***