The way we handle interactions on toolbar buttons is extremely inconsistent right now. The hamburger menu and the bookmarks menu use mousedown, most other things use mouseup. Generally, using mousedown gets us a perceived perf win, but we probably shouldn't use it for actions, since it can't be cancelled. We should come up with a more consistent model here, or at least document/describe what we have in a more coherent manner.

It seems that, as you pointed out, actions should react to onmouseup, but buttons that open/unfold menu should react to menudown. It seems that at least on Mac and Gnome, the "mousedown opens a window, mouseup activates an action" is pretty consistently used in the HiG. On Gnome, the main menu uses it (File, Open etc.) in all apps, including in Firefox. The global menu (the one opened via topbar clicking on the active app icon) as well. In order to become consistent it seems we just need: - hamburger menu actions to react to onmouseup - toolbar icons that open menus (Library, Download Panel, Bookmarks etc.) to react to onmousedown There seem to be several more complex items: - sliding panels (as pointed in bug 1366074) require some logic to notice mouseover, and react after delay - dual action buttons (back, forward) which both can be an action and open a menu, should perform an action if mousedown+mouseup is faster than the delay that opens the menu, but once the menu is open, they should not perform an action on mouseup. I believe that the more complex items can be resolved as followups, and we could just start with getting the menu-opening icons in toolbar and hamburger menu actions to use the right event. Does it sound reasonable Philipp? I'd be happy to volunteer to write the code.

That does sound very reasonable! I was actually just looking at this on our reference hardware today, and it is amazing how much faster mousedown menu open feels on less-than-great touchpads. There's only one bit that I don't fully understand: > - hamburger menu actions to react to onmouseup The items inside the hamburger menu already do react on mouseup and the hamburger button itself should keep its current behavior (open on mousedown), so I'm not sure which items you are referring to. > There seem to be several more complex items: > - sliding panels (as pointed in bug 1366074) require some logic to notice mouseover, and react after delay > - dual action buttons (back, forward) which both can be an action and open a menu, should perform an action if mousedown+mouseup is faster than the delay that opens the menu, but once the menu is open, they should not perform an action on mouseup. > > I believe that the more complex items can be resolved as followups, and we could just start with getting the menu-opening icons in toolbar and hamburger menu actions to use the right event. Agreed! One item that we shouldn't forget is the page actions menu (...)

cool! This effort will take a while since it seems that there are several ways to denote buttons and menuitems that open menus, submenus or activate items. I started by switching the menu opening items to react to mousedown in bug 1395871. Next I'll try to get the menuitems to react to mouseup.

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #2) > There's only one bit that I don't fully understand: > > - hamburger menu actions to react to onmouseup > The items inside the hamburger menu already do react on mouseup and the > hamburger button itself should keep its current behavior (open on > mousedown), so I'm not sure which items you are referring to. They don't react to mouseup if you mousedown on the hamburger button, then keep the mouse pressed and mouse up on the item, which works for "normal" menus. I assume that's what gandalf is talking about.