Closed Bug 50504 Opened 24 years ago Closed 18 years ago

Context menu (right-click) for bookmarks (in main menu and Personal Toolbar)

Categories

(SeaMonkey :: Bookmarks & History, enhancement, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: BenB, Assigned: bugzilla)

References

Details

(Keywords: fixed-seamonkey1.1a, relnote)

Attachments

(1 file, 3 obsolete files)

Context menu patch v3
4.24 KB, patch
neil
: review+
iannbugzilla
: approval-seamonkey1.1a+
Details | Diff | Splinter Review 
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. ***
Blocks: 35942, 50502
Blocks: 19437
No longer blocks: 50502
Reassigning to default component owner since slamm isn't here anymore.
Assignee: slamm → ben
Keywords: helpwanted
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.
Depends on: 64324
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: nsbeta1-
is this ment for manage bookmarks or for a normal menu?
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
*** 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'.
Assignee: ben → pchen
*** 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
Assignee: pchen → 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.
Depends on: 172276
No longer depends on: 64324
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.
Blocks: 116531
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?
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 ???????????
Depends on: 160019
*** 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 ...

Thank you for volunteering to work on so many bugs, let's start with this one.
Assignee: ben → paolo.marani
*** 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!
Blocks: majorbugs
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!
Assignee: paolo.marani → p_ch
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
Summary: Context menu for bookmarks menus → Context menu (right-click) for bookmarks in folders on Personal Toolbar
This bug is not (primarily) about the personal toolbar, but the real menu
Summary: Context menu (right-click) for bookmarks in folders on Personal Toolbar → Context menu (right-click) for bookmarks
(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
Summary: Context menu (right-click) for bookmarks → Context menu (right-click) for bookmarks (in main menu and Personal Toolbar)
(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...
Product: Browser → Seamonkey
*** Bug 281229 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
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?
Assignee: p_ch → nobody
QA Contact: claudius → bookmarks
(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?
No longer blocks: 116531
(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.
Attached patch Context menu patch (obsolete) — — Splinter Review 
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.
Attachment #230719 - Flags: review?(neil)
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?
Attached patch Context menu patch v2 (obsolete) — — Splinter Review 
(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.
Attachment #230719 - Attachment is obsolete: true
Attachment #231042 - Flags: review?(neil)
Attachment #230719 - Flags: review?(neil)
(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!
Attached patch Context menu patch v2.1 (obsolete) — — Splinter Review 
(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.
Attachment #231042 - Attachment is obsolete: true
Attachment #231193 - Flags: superreview?(neil)
Attachment #231193 - Flags: review?(neil)
Attachment #231042 - Flags: review?(neil)
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.
Attachment #231193 - Attachment is obsolete: true
Attachment #231702 - Flags: review?(neil)
Attachment #231193 - Flags: superreview?(neil)
Attachment #231193 - Flags: review?(neil)
Depends on: 347144
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.
Attachment #231702 - Flags: review?(neil) → review+
(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?
Assignee: nobody → paradigmk
Keywords: helpwanted
Fix checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 231702 [details] [diff] [review]
Context menu patch v3

'approval-seamonkey1.1a  	 =?':
Wanted 1.1 feature.
Attachment #231702 - Flags: approval-seamonkey1.1a?
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
Attachment #231702 - Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
Whiteboard: [1.8 branch checkin: Wait for bug 347144 checkin first !]
Fix checked in to the branch.
Keywords: fixed-seamonkey1.1a
Whiteboard: [1.8 branch checkin: Wait for bug 347144 checkin first !]
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.
Status: RESOLVED → VERIFIED
*** Bug 19437 has been marked as a duplicate of this bug. ***
Blocks: 164421
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. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: