Closed Bug 195031 Opened 21 years ago Closed 16 years ago

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

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3 alpha8

People

(Reporter: p_ch, Assigned: enndeakin)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 2 obsolete files)

address issues
18.85 KB, patch
asaf
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
for instance when rclicking on a menu and selecting cut, delete, paste, new
folder, properties...
OS: Linux → All
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
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.
*** Bug 243202 has been marked as a duplicate of this bug. ***
Flags: blocking1.0?
-ing, would consider patch
Flags: blocking1.0? → blocking1.0-
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?
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. ***
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".
*** Bug 262590 has been marked as a duplicate of this bug. ***
*** Bug 269630 has been marked as a duplicate of this bug. ***
Blocks: 214881
*** Bug 269963 has been marked as a duplicate of this bug. ***
Assignee: vladimir → vladimir+bm
*** Bug 272936 has been marked as a duplicate of this bug. ***
*** Bug 277546 has been marked as a duplicate of this bug. ***
*** Bug 280575 has been marked as a duplicate of this bug. ***
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?
*** Bug 276388 has been marked as a duplicate of this bug. ***
(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. ***
(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.
Putting this back on the map again for Firefox 1.1 and hopefully someone can
pick it up.
Flags: blocking-aviary1.1?
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-
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. ***
*** 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. ***
*** 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
*** 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. ***
(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.
(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-
(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. ***
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+
Yes, this is pretty easy once the big popup reworking (bug 279703) is done.
Depends on: 279703
Target Milestone: --- → Firefox 3 beta1
Attached patch simple support (obsolete) — — Splinter Review 
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.
Attachment #271105 - Flags: ui-review?(beltzner)
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?.
(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?
(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.
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]
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.
(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.
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
(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...
(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.
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Whiteboard: [need ui-review beltzner]
Attachment #271105 - Flags: ui-review?(beltzner) → ui-review+

        Attachment #271105 -
        Attachment is obsolete: true

        Attachment #278058 -
        Flags: superreview?(bzbarsky)

        Attachment #278058 -
        Flags: review?

    
  

        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?

    
    

    
  
(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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        address issues
        — 
          — Splinter Review
      

    


  
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+
Whiteboard: [need ui-review beltzner] → [patch has r+sr]

    
  
Keywords: checkin-needed

    
  
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED

    
    

    
  
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]

    
    

    
  
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

    
    

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

~B

    
  
Blocks: 394397

    
  
Depends on: 394400

    
  
Depends on: 394401

    
  
No longer depends on: 394400

    
  
No longer depends on: 394401

    
  
Flags: in-testsuite+

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
(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
Depends on: 404311

    
    

    
  
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.


    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
  
Keywords: dev-doc-complete

          You need to log in
          before you can comment on or make changes to this bug.