TopChrome [bookmarks bar] bug.

just started

+bettes/sky

I don't think we should do this. Or, at least, the right fix is not simple (tl;dr we need cursor vectors).

Although this is (mostly) true for Mac native menus, it is _not_ true for the current Cocoa browser bookmarks bar. And I think there's a good reason.

Note Mac native NSMenus do not support drag and drop. The Cocoa browser bookmarks bar and all toolkit-views menus _do_ support drag and drop. That may be something to consider.

*But*, more importantly, Mac NSMenus have another smart feature that I don't think we implement and the simple approach in https://chromium-review.googlesource.com/c/chromium/src/+/1063014 could cause a bad regression.


In fact, NSMenus do not _always_ disappear as soon as you hover over another menu item. Whether they disappear or not depends on the _vector of cursor movement_. I don't think we have any logic considering this.

For native Cocoa menus, when you have a submenu open and move the mouse in a *diagonal* line from the menu parent to an item in the submenu, you may hover over other menu items along that path that _would_ take hover and open a submenu, but they do not. This is due to special logic looking at the mouse cursor vector. If those other submenus along that path _did_ open it would be a very poor UX.

I think toolkit-views avoids the poor UX with a timer rather than cursor vectors (sibling submenu parents do take _hover_ but only open after a delay).

The proper fix for this may be to incorporate cursor vectors into the toolkit-views menu system. This would make submenus in chrome feel "snappier".

Playing with GTK menus.. I think they do something similar to Cocoa. Native Windows menus seem to work more similarly to toolkit-views. (i.e. toolkit-views has adopted the Windows native behavior).



IMO, we don't need to treat this as a regression. I doubt many users on Mac use the `Bookmarks` menu via the hamburger, since it's repeated in the mainMenu bar at the top of the screen (which isn't changing). Compared to the bookmarks toolbar on Cocoa vs Views browsers, the behavior is also not changing.

But, I do think we should implement cursor vectors for toolkit-views menus. Just not as a priority.

Further reading

 - http://www.mackido.com/Interface/hysteresis.html
 - http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
 - https://www.webmaster-source.com/2013/03/20/how-amazon-solved-the-dropdown-delay-problem/
 - https://css-tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/


choice quote :)

"As it turns out, Apple has been using the same principle for their OS’s menus for a long time. At least since the early 1990s, perhaps earlier, though I’m not familiar enough with Apple’s history to pinpoint exactly when. It’s funny how often the wheel is reinvented..."

Thanks for such detailed information!

I don't think we have time to imp cursor vector now. My next question is would Mac users mind the menu opening a bit longer? Since the current mechanism serves Linux/GTK users well, can I assume not fixing it is ok for now? If so, I will file a separate feature request to imp cursor vector for menus.

if it's consistent with kDragHoverCloseDelay (https://cs.chromium.org/kDragHoverCloseDelay - 400ms) that the cocoa bookmarks bar menus have been using since forever then, IMO, it's fine for now.

(note I think it is consistent -- views::MenuConfig::show_delay is 400ms also).

kDragHoverCloseDelay is used during drag&hover only. It doesn't apply to our case -- hover only.

To make this case clear, if you open Cocoa browser setting menu (three dots menu) with a submenu, when you leave that submenu, the submenu immediately closes. For MacViews, as long as the cursor keeps moving, the submenu will be there forever.

That said, I think this is not a big issue because once the cursor stays over a submenu or somewhere else for a bit, that action will trigger the previous submenu close.


 

Filed a new feature request for cursor vector implementation crbug.com/849439
Closing this now.