Created attachment 8878803 [details] comparison between sub menus Steps to reproduce: 1. open Nightly 56.0a1 (2017-06-17) (64-bit) on OSX 2. click hamburger button 3. hover on "Web Developer >" menu item 4. click "Web Developer" 5. click "Tools" in the menu at the top of the screen 6. hover on "Web Developer >" menu item Actual result: 3. nothing happens 4. the content slides to sub menu and the original menu disappears 6. sub menu opens next to the menu item Expected result: those 2 menu items should behave in the same way it's not intuitive to have 2 similar things on the screen that behave differently. the behavior at the step 6 is how sub menu behaves, that should be consistent across applications on the same OS so, at the step 3, sub menu should open next to the menu
We won't do this (see also bug 1366074). This is also not really a change from before - we have had these sliding subviews in the main hamburger panel for a while, as well as in the downloads panel and identity popup.
(In reply to :Gijs from comment #1) > We won't do this (see also bug 1366074). This is also not really a change > from before - we have had these sliding subviews in the main hamburger panel > for a while, as well as in the downloads panel and identity popup. but now the panel looks like a menu, that is different from before. previously the panel looks totally different from a standard menu, so different behavior doesn't matter, but now the panel looks almost like a standard menu. if we imitate a menu, we shouldn't do different thing.
(In reply to Tooru Fujisawa [:arai] from comment #2) > (In reply to :Gijs from comment #1) > > We won't do this (see also bug 1366074). This is also not really a change > > from before - we have had these sliding subviews in the main hamburger panel > > for a while, as well as in the downloads panel and identity popup. > > but now the panel looks like a menu, that is different from before. > > previously the panel looks totally different from a standard menu, so > different behavior doesn't matter, > but now the panel looks almost like a standard menu. > if we imitate a menu, we shouldn't do different thing. So, schedule-wise, this is going to be almost impossible to implement for 57 at this point. It would require rewiring everything. I'm also not sure how easy menus with custom styling (e.g. for the zoom/edit controls). But maybe Bryan or Aaron can explain the thinking here for posterity, and/or make a decision about whether we want to do this long-term.
The submenus work as designed to allow for greater depth of navigation. The flyout menu approach becomes difficult to manage once you get more than 2 layers deep in a hierarchy.
that doesn't answer the consistency issue...
The menus aren't consistent with macOS but they don't necessarily have to be. It's more important that the menus within Firefox are consistent with each other, which is why we've adopted this approach.
if the UIs are not consistent across applications, how users can operate on it without failing several times? also, 2 menus in https://bug1373966.bmoattachments.org/attachment.cgi?id=8878803 are both Firefox's, so currently it's not consistent even within Firefox.
also, there are so many places that uses standard sub menu (flyout one) all around Firefox UI, like bookmark toolbar, context menu, etc. is there any plan to replace all of them with the sliding style?
Yes. All of the toolbar menus will behave as sliding menus.
only toolbar menus? how about context menu or the menu at the top of the screen, or menu at somewhere else than toolbar?
The context menus and the one at the top of the screen (Menu Bar) are driven by the operating system and can't be modified.
so, it means that the consistency within Firefox is not achievable if you go with sliding menu.
Yeah, solid point. I shouldn't have phrased it that way. What I meant was the menus in the toolbar are designed with the sliding menu.
okay, so the reasoning behind using sliding menu is only to manage deeply layered hierarchy easily, right? if flyout submenu cannot be used for that reason (I'm not yet sure why it needs to be only single pane at once tho), I'd suggest to stop imitating the standard menu styling (especially ">" mark) and make it clear it's different UI component that needs different operation.
I'm one of people who is confused from this styling. (In reply to Tooru Fujisawa [:arai] from comment #14) > if flyout submenu cannot be used for that reason (I'm not yet sure why it > needs to be only single pane at once tho), I'd suggest to stop imitating the > standard menu styling (especially ">" mark) and make it clear it's different > UI component that needs different operation. I also think so. Actually I'm living with Firefox, but I'm also living with other applications - Adobe Illustrator, LibreOffice, and others. When I switch my task between these applications, current (sliding with submenu-like appearance) design confuses me every time.
also, I think the following points should also be reconsidered: 1. are there so many deeply layered sub menus? (IMO, 2 or 3 layered sub menus with flyout style won't become a trouble) 2. is it worth addressing operability about deeply layered sub menus even with introducing difficulty for single or a few layered sub menus? (with current way, user needs to click, that doesn't match to OS and other places inside Firefox, and also just requiring extra click is also bad) 3. why are we showing only one pane at a time? (bug 1366074 comment #c5 points out that that's the source of the issue there) then, to be clear, what I propose here is doing either: A. use flyout submenu that opens by hovering (that matches to standard menu) B. make it distinct from standard menu, and make it look like a button or something that deserves a click to activate A is the best way, and B is alternative way that may require less change.
this bug should be kept opened, even if it cannot be fixed before firefox 57. there's no good reasoning about inconsistency inside application and across applications.