The default bug view has changed. See this FAQ.

Bookmarks menus should be sticky (should remain open in some cases)

VERIFIED FIXED in Firefox 3 alpha8

Status

()

Firefox
Bookmarks & History
VERIFIED FIXED
14 years ago
8 years ago

People

(Reporter: Pierre Chanial, Assigned: Neil Deakin)

Tracking

({dev-doc-complete})

Trunk
Firefox 3 alpha8
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
for instance when rclicking on a menu and selecting cut, delete, paste, new
folder, properties...

Updated

14 years ago
OS: Linux → All
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor

Comment 2

13 years ago
I agree with Pierre.  Keeping the Bookmarks menu "sticky" after performing
operations like cutting or deleting gives the user visual feedback and
confirmation that the menu item has indeed been cut or deleted.  

It's also a convenience feature for copying or pasting; the menu stays open so
the user can locate the place where the bookmark item will be pasted, and again
provides a visual confirmation that the bookmark item has been pasted in the
correct location.

Comment 3

13 years ago
*** Bug 243202 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking1.0?
-ing, would consider patch
Flags: blocking1.0? → blocking1.0-

Comment 5

13 years ago
Vlad, any chance you can help us with this for 1.0? It really does make managing
bookmarks in the menu (from what I understand, a very common IE usage pattern)
darned painful. 
Assignee: p_ch → vladimir
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Comment 6

13 years ago
I'd like to add middle-click to the list of commands that should not close the menu.
that would be counter-intuitive, its closer to left-click than any of the
"management" type options.
*** Bug 254665 has been marked as a duplicate of this bug. ***
Nice idea, but sounds risky as far as menu code goes. May reconsider with a patch. 
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
*** Bug 256863 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
Just wanted to make sure that this fix will also apply to Live Bookmarks, i.e.
don't close the menu after clicking "refresh live bookmark".

Comment 12

13 years ago
*** Bug 262590 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
*** Bug 269630 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 214881

Comment 14

13 years ago
*** Bug 269963 has been marked as a duplicate of this bug. ***
Assignee: vladimir → vladimir+bm

Comment 15

13 years ago
*** Bug 272936 has been marked as a duplicate of this bug. ***

Comment 16

12 years ago
*** Bug 277546 has been marked as a duplicate of this bug. ***
*** Bug 280575 has been marked as a duplicate of this bug. ***

Comment 18

12 years ago
If Shift is held when clicking on a program in the Start Menu, then the menu
stays open, allowing several programs to be launched without re-opening said
menu. This also applies to the Favourites menu in IE, of course with almost no
use since it won't open new windows.

If menu stickiness isn't default for middle-click, could Shift be used as a
modifier to keep the menu open?

Comment 19

12 years ago
*** Bug 276388 has been marked as a duplicate of this bug. ***

Comment 20

12 years ago
(In reply to comment #0)
> for instance when rclicking on a menu and selecting cut, delete, paste, new
> folder, properties...

I have a complaint,  and I think it's close enough to this subject that it
doesn't warrant a separate bug report. (Still new to the system)

I've got all my bookmarks under the "Personal Toolbar Folder",  with
multiply-nested folders.  So I click on one of the root folders,  and mouse over
a desired interior folder.  But as I move the mouse over,  it might nudge one of
the adjacent folders;  the menu closes and is replaced by the menu for the
folder my mouse is now over.  

That's fine,  since I haven't given the browser any indication that I was
interested in that particular folder.  But the behavior doesn't change if I
first click on the folder of interest.  It seems like,  having clicked it,  I've
indicated that I'm interested in that folder,  and it should stay open at least
long enough for me to move my mouse over whatever bookmark I'm interested in.

Steps to reproduce:  

1) Have a folder 'A' in the Personal Toolbar Folder,  containing two or more
sub-folders 'B' and 'C',  each with a list of bookmarks.

2) Click on folder A.  This drops down a list containing folders 'B' and 'C'.

3) Move mouse over folder B.  Its contents should open.

4) Try moving the mouse directly to one of the bookmarks at the bottom of B's
list,  passing over the screen area displaying folder C.  When your mouse moves
below folder B,  B's subfolder should close (unless you move very quickly.  Too
quickly.  If there is a set time for this,  I think it should be increased).

5) Again,  click on folder A and mouse over folder B.  This time,  click on
folder B.  

Expected: The list of bookmarks in folder B should remain open thereafter, 
until you either click on a bookmark,  click the main window,  or click on a
bookmark in the parent menu.

What happens:  B's list closes as soon as your mouse leaves folder B.

I find it very annoying,  as I have to be very careful about keeping my mouse
hovering over folder B until I'm to B's list,  even though I could go exactly to
the bookmark I want by moving diagonally.
*** Bug 294391 has been marked as a duplicate of this bug. ***
*** Bug 294573 has been marked as a duplicate of this bug. ***
*** Bug 295125 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
(In reply to comment #23)
> *** Bug 295125 has been marked as a duplicate of this bug. ***

Sorry for "bug spamming", I am new to this. I got back "Assigned to" on my bug
report "Nobody's working on this, feel free to take it". Sure, I would love to
help, but I have no idea of how to "work on this". Some suggestions, guidelines,
pointers, instructions, etc. would be most helpful. What would I have to do in
order to work on this? Should I download a nightly build and then look in the
source of the project and try to modify a source file and then rebuild the
project too see if my contribution is helpful, resolves the issue, and does not
introduce new bugs? Information and instructions on how to fix this issue would
be very much appreciated.

Comment 25

12 years ago
Putting this back on the map again for Firefox 1.1 and hopefully someone can
pick it up. 
Flags: blocking-aviary1.1?

Comment 26

12 years ago
Thank you for putting this back on the TODO list, Chris. This is probably a very
trivial matter, the Bookmarks menu closes after sorting and one has to open it
again manually to see the changes, but small polish like this does add up to
something, especially for IE users that would consider switching browsers. I
would do it myself but I don't know how to code. Perhaps some coder familiar
with Firefox's Bookmarks menu could implement this change. I will help with
documentation if anyone would offer me the work, I am good with writing
documents. Thanks again everyone, Firefox is an awesome project and really does
blow away Internet Explorer with features and security. I made the switch to
default browser when I watched IE install 5 malware programs by visiting a
malicious web site, the only indication I had of this happening was a small
"Installing Active-X components" message in the lower right hand side of IE.
Very scary, very much dumped Internet Explorer after that.
This would be nice, but in the current state of the underlying menupopup code,
this isn't practical/safe, especially at this stage of the game.  I want to get
the underlying issues fixed, and have a sane and safe implementation to build on.

For those who wonder why this isn't safe, please look at bug 210910 to see how
rickety context-on-menupopup is currently.
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 28

12 years ago
That was a very practical explanation, thank you for taking the time, Mike. I
agree that security is more important than cosmetics at this stage of the game,
that is what turned me off IE. I won't "bug" you about it anymore. Thanks for
the serious efforts you and the team are making with Fireforx. The browser is
totally awesome.
*** Bug 296761 has been marked as a duplicate of this bug. ***
Hardware: PC → All
Version: unspecified → Trunk
Summary: Bookmarks menus should be sticky, in some cases → Bookmarks menus should be sticky (should remain open in some cases)
*** Bug 252124 has been marked as a duplicate of this bug. ***

Comment 31

12 years ago
*** Bug 299614 has been marked as a duplicate of this bug. ***
*** Bug 257057 has been marked as a duplicate of this bug. ***
*** Bug 301925 has been marked as a duplicate of this bug. ***
*** Bug 304315 has been marked as a duplicate of this bug. ***

Comment 35

12 years ago
*** Bug 310699 has been marked as a duplicate of this bug. ***
*** Bug 311826 has been marked as a duplicate of this bug. ***
Assignee: vladimir+bm → nobody

Comment 37

12 years ago
*** Bug 314493 has been marked as a duplicate of this bug. ***
*** Bug 320067 has been marked as a duplicate of this bug. ***
*** Bug 321749 has been marked as a duplicate of this bug. ***

Comment 40

11 years ago
(In reply to comment #27)
> This would be nice, but in the current state of the underlying menupopup code,
> this isn't practical/safe, especially at this stage of the game.  I want to get
> the underlying issues fixed, and have a sane and safe implementation to build on.
> 
> For those who wonder why this isn't safe, please look at bug 210910 to see how
> rickety context-on-menupopup is currently.

Mike, are the issues you mentioned above still the case?  I notice 210910 has been fixed.  Do you think we can get this resolved for 2.0?

Bryan
Flags: blocking-firefox2?
QA Contact: mconnor → bookmarks
bug 210910 was fixed via a hacky workaround (which was recently pulled into Places because they had the same problem), the core issue still exists, and trying to be selective in how that hack works isn't really something that's worth tempting fate for.

Comment 42

11 years ago
(In reply to comment #41)
> bug 210910 was fixed via a hacky workaround (which was recently pulled into
> Places because they had the same problem), the core issue still exists, and
> trying to be selective in how that hack works isn't really something that's
> worth tempting fate for.

Well hopefully someone with knowledge of this code can step up with a solution for this bug as it's very frustrating when attempting to move bookmarks around in the bookmarks menu and then menu disappears on you.  I don't care to launch Places to do the same as many more clicks are required to do something that one should be able to do easily through drag and drop!  

Just so you know the Bookmarks menu IS sticky upon the second try!  The first time I attempt to drag a bookmark to another folder the bookmarks menu closes.  Every subsequent time it remains sticky.  Can we fix the issue of the first time it not being sticky?

~B
Will take a patch for this, but not going to block on it.  The long long ago assessment was that to fix this correctly requires a rewrite of how menupopups work, and that's not something we're going to do in this timeframe.  Will follow up with the right people to look at fixing this in Gecko 1.9
Flags: blocking-firefox2? → blocking-firefox2-

Comment 44

11 years ago
(In reply to comment #43)
> Will take a patch for this, but not going to block on it.  The long long ago
> assessment was that to fix this correctly requires a rewrite of how menupopups
> work, and that's not something we're going to do in this timeframe.  Will
> follow up with the right people to look at fixing this in Gecko 1.9

Now that places has been taken off the FF 2.0 plate, is this something that can happen?

~B
*** Bug 336537 has been marked as a duplicate of this bug. ***
*** Bug 336600 has been marked as a duplicate of this bug. ***
*** Bug 356868 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Flags: blocking-firefox3?
Neil, can you take a look at this and figure out what needs to happen?
Assignee: nobody → enndeakin
Flags: blocking-firefox3? → blocking-firefox3+
(Assignee)

Comment 49

10 years ago
Yes, this is pretty easy once the big popup reworking (bug 279703) is done.
Depends on: 279703
Duplicate of this bug: 379172
Duplicate of this bug: 329369

Updated

10 years ago
Target Milestone: --- → Firefox 3 beta1
(Assignee)

Comment 52

10 years ago
Created attachment 271105 [details] [diff] [review]
simple support

This patch adds a closemenu attribute for menuitems:
  closemenu="single" - close only one menu when item is selected
  closemenu="none" - close no menus when item is selected
  closemenu="auto" (default) - close entire chain of menus

I added this attribute to some of the commands on the bookmarks context menu, so that we can test this out and see if we like it before continuing.
(Assignee)

Updated

10 years ago
Attachment #271105 - Flags: ui-review?(beltzner)

Comment 53

10 years ago
Since Bookmarks on Places landed, the bookmarks menu closes itself after I drag and drop an item in it.
Will this bug revert the menu behavior to what it was before Places (i.e. the menu stayed open after drag and drop of an bookmark item in the bookmarks menu) as well?.

Comment 54

10 years ago
(In reply to comment #53)
> Since Bookmarks on Places landed, the bookmarks menu closes itself after I drag
> and drop an item in it.
> Will this bug revert the menu behavior to what it was before Places (i.e. the
> menu stayed open after drag and drop of an bookmark item in the bookmarks menu)
> as well?.
> 

Just to make sure we are on the same page, have you tried the very latest nightlies?  Because they have this mostly fixed.  I don't think this was ever fixed before now.  Can you clarify?

Comment 55

10 years ago
(In reply to comment #54)
> Just to make sure we are on the same page, have you tried the very latest
> nightlies?  Because they have this mostly fixed.  I don't think this was ever
> fixed before now.  Can you clarify?

I just tried Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre (should be the latest nightly) as fresh installation with new profile. I was trying to drag only in the menu, from menu to subfolder and vice versa. The bookmarks menu always closed itself.

Comment 56

10 years ago
Odd.  It works in yesterday's build (the 12th).  What was pulled out between yesterday and today that would have broken this again?


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071205 Firefox/3.0a6pre ID:2007071205 [cairo]

Comment 57

10 years ago
Wait, I just tried today's build, and it still worked, but I realized what the problem is.  This is fixed within Bookmarks Toolbar Folders, but not on the Bookmarks menu.  Try it out within folders on the Bookmarks Toolbar.

Comment 58

10 years ago
(In reply to comment #57)
> Wait, I just tried today's build, and it still worked, but I realized what the
> problem is.  This is fixed within Bookmarks Toolbar Folders, but not on the
> Bookmarks menu.  Try it out within folders on the Bookmarks Toolbar.

Can't reproduce here, the bug also applies to any Bookmarks Toolbar (Sub-)Folder.

Comment 59

10 years ago
So should I expect to be able to right-click on a Bookmarks submenu, right-click and "Sort by Name" and the menu be sticky?  That is my expectation!  The bookmarks menu and it's submenus should behave exactly like the Windows start menu and all of it's submenus.

I downloaded yesterdays nightly and it still appears that I what I expect is still not functioning properly in that the Bookmarks menu and it's submenus still close when I expect that they still open while i'm "working" in them.

Bryan

Comment 60

10 years ago
(In reply to comment #59)
> That is my expectation!

Good, but only after this bug is fixed. It's not.

@Everyone: the recent minefield regressions have nothing to do with this bug. They are new bugs, such as bug 337761 and all relatives. Please don't spam this bug for that, it really doesn't help anyone...

Comment 61

10 years ago
(In reply to comment #60)
> (In reply to comment #59)
> > That is my expectation!
> 
> Good, but only after this bug is fixed. It's not.
> 
> @Everyone: the recent minefield regressions have nothing to do with this bug.
> They are new bugs, such as bug 337761 and all relatives. Please don't spam this
> bug for that, it really doesn't help anyone...
> 

I, for one, am talking about certain portions of this bug being FIXED, not broken, but no one has confirmed what I have found above.

Updated

10 years ago
Target Milestone: Firefox 3 M7 → Firefox 3 M8

Updated

10 years ago
Whiteboard: [need ui-review beltzner]

Updated

10 years ago
Duplicate of this bug: 390529
Attachment #271105 - Flags: ui-review?(beltzner) → ui-review+
(Assignee)

Comment 63

10 years ago
Created attachment 278058 [details] [diff] [review]
add closemenu attribute to control this, include test
Attachment #271105 - Attachment is obsolete: true
Attachment #278058 - Flags: superreview?(bzbarsky)
Attachment #278058 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #278058 - Flags: review? → review?(mano)
Comment on attachment 278058 [details] [diff] [review]
add closemenu attribute to control this, include test

>Index: layout/xul/base/src/nsXULPopupManager.cpp
>+  nsAutoString closemenu;
>+  aMenu->GetAttr(kNameSpaceID_None, nsGkAtoms::closemenu, closemenu);
>+  if (closemenu.EqualsLiteral("none"))
>+    cmm = CloseMenuMode_None;
>+  else if (closemenu.EqualsLiteral("single"))
>+    cmm = CloseMenuMode_Single;

Is there a reason not to use FindAttrValueIn here?

>+    nsAutoString id;

Is this actually used?  I don't see where....

>-                   "popup is open list not actually open");
>+                   "popup in open list not actually open");

What's changing here?

>-                   "popup is open list not actually open");
>+                   "popup in open list not actually open");

And here?
(Assignee)

Comment 65

10 years ago
(In reply to comment #64)
> >+    nsAutoString id;
> 
> Is this actually used?  I don't see where....
> 
Something left over from debugging, which I'll remove

> >-                   "popup is open list not actually open");
> >+                   "popup in open list not actually open");
> 
> What's changing here?

Just fixing the grammar in both cases: /is/in/
Status: NEW → ASSIGNED
(Assignee)

Comment 66

10 years ago
Created attachment 278412 [details] [diff] [review]
address issues

Also remove the closemenu attribute from the new bookmark and new folder items as they open dialogs, and fix a missing > in the testcase.
Attachment #278058 - Attachment is obsolete: true
Attachment #278412 - Flags: superreview?(bzbarsky)
Attachment #278412 - Flags: review?(mano)
Attachment #278058 - Flags: superreview?(bzbarsky)
Attachment #278058 - Flags: review?(mano)
Comment on attachment 278412 [details] [diff] [review]
address issues

sr=bzbarsky
Attachment #278412 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 278412 [details] [diff] [review]
address issues

r=mano
Attachment #278412 - Flags: review?(mano) → review+

Updated

10 years ago
Whiteboard: [need ui-review beltzner] → [patch has r+sr]

Updated

10 years ago
Keywords: checkin-needed
(Assignee)

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 69

10 years ago
The following commands now don't close the menu when used:
  new separator, delete, reload, sort by
Keywords: checkin-needed
Whiteboard: [patch has r+sr]

Comment 70

10 years ago
I actually want the menu to stay open when I add a new separator or delete or sort item in a bookmark menu when it's open just like IE6 does.  This still doesn't behave exactly as I would it expect it though.  Behavior is inconsistent.  Cut/Copy/Paste in the menu and it isn't sticky but using Delete it is.  What is that about?  Also attempting to D&D an item between menus and the indication of where it's going to go when you release the mouse is one item below where you actually have your mouse pointer!  That's very confusing unless you notice the highlight!!!

~B

Comment 71

10 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=394397 opened for the issues I mentioned above.

~B

Updated

10 years ago
Blocks: 394397

Updated

10 years ago
Depends on: 394400

Updated

10 years ago
Depends on: 394401
(Assignee)

Updated

10 years ago
No longer depends on: 394400
(Assignee)

Updated

10 years ago
No longer depends on: 394401
(Assignee)

Updated

10 years ago
Flags: in-testsuite+

Comment 72

10 years ago
What about dragging bookmarks around within the folder (reordering them)?  The menu should remain open then, as well.  That is the reason I voted for this bug in the first place.  Should a new enhancement request be created?  This was actually working a few months ago in the trunk, but then it mysteriously stopped.
(Assignee)

Comment 73

10 years ago
(In reply to comment #72)
> What about dragging bookmarks around within the folder (reordering them)?  The
> menu should remain open then, as well.  That is the reason I voted for this bug
> in the first place.  Should a new enhancement request be created? 

Yes, as this bug is not about dragging. That is, comment 1 makes no mention of dragging. If that is a regression, it should be marked with the regression keyword.

what exactly was fixed here? that is what actions cause menu stickiness and to what extent does the menu remain sticky?  

For example.  context click a bookmark in the bookmark menu, click "Cut".  Is the bookmark menu supposed to remain so you can then context click in it again to perform another action (paste)?    If that is what is supposed to happen, tis big is not fixed.  Tested on Windows Trunk build from 20070905.  Mac context click in bookmark menus is completely broken so I can't check it there.
(Assignee)

Comment 75

10 years ago
(In reply to comment #74)
> what exactly was fixed here? that is what actions cause menu stickiness and to
> what extent does the menu remain sticky?  
> 

1. Open a bookmark menu
2. Context-click on an item
3. When either the new separator, delete, reload, or sort by commands from the context menu are selected, the context menu closes, yet the bookmark menu remains open.

There is a followup bug 394397 about extending this to cut/copy/paste.

Context menus on bookmarks aren't supported on the Mac.
Excellent, Thank you Neil.  Verified the actions you laid out work as expected on Windows trunk build from 20070905
Status: RESOLVED → VERIFIED

Updated

10 years ago
Duplicate of this bug: 396766

Updated

10 years ago
Depends on: 404311

Comment 78

10 years ago
Not everything works.

Bug 356868 was previously marked a duplicate of this bug, but the request of that bug, which is to make "Open in New Tab" sticky, has not been addressed with the resolution of this bug.

In short, a live bookmark when opened in a new tab by either middle-clicking, ctrl+clicking, or using the menus, should leave the menu open to allow the user to select the next entry he or she is interested in.

Comment 79

10 years ago
Seems to me that this is still inconsistently implemented.  A great example of this is, let's say I want to "Sort By Name" while viewing the contents of one of my bookmark folders.  I right click in the expanded bookmark folder and observe that I cannot "Sort By Name" here.  I then move my mouse to the parent folder and right click but then lose the bookmark menu!  This could be an entirely different bug (not being able to "Sort By Name" while in a bookmark folder content view).  

When dragging and dropping bookmarks between folders in the bookmark menu, it's my expectation that the bookmark menu will remain sticky but it does not.

~B
(Assignee)

Updated

9 years ago
Duplicate of this bug: 94915

Comment 81

9 years ago
I agree with Bryan's observations in FF3.  This is very unintuitive, especially for users that have always expected the Sort By Name option to be available on the sub-items.  Right-clicking another part of the bookmarks menu should not close it.

Updated

9 years ago
Duplicate of this bug: 437171

Comment 83

9 years ago
I think the Sort by Name thing is bug 400447. But you're right, this bug should be reopened - after dragging and dropping a bookmark to a different folder, the bookmarks menu closes.

Comment 84

8 years ago
This bug (menu closing too quickly not allowing sort, edit, rename etc) is still on FF3. It's a nightmare really. It's completely against the grain for a Windows user.

It can be partly fixed by using Stay Open https://addons.mozilla.org/en-US/firefox/addon/6459 but I don't middle click much. I eased the 'close menu' pain by following http://ask.metafilter.com/40700/Firefox-menu-delay (set it to 1500) which at least slows down submenus from opening when you have to constantly go back and forth to where you were to simply confirm, edit or oggle at your new bookmark. I move bookmarks around a lot and it's very very difficult with the menus closing before the simplest of tasks is complete.

How difficult can it be to leave the menu 'open' or a little sticky? I don't know because I have no idea about these things but it would be nice to have menus work like menus within Windows (and I suppose Internet Explorer).

Thanks.
(Assignee)

Updated

8 years ago
Keywords: dev-doc-complete
You need to log in before you can comment on or make changes to this bug.