In other native Vista applications, the menubar can be displayed or hidden by pressing the alt key. The menubar should still be displayed by default on Vista (at least until we consider various alternatives to be more native), this bug is just to add the expected behavior of being able to toggle it on or off.
Which native Vista applications have this behavior? In every native windows application (those with native menus that is), the Alt key triggers access key mnemonics on keydown and gives focus to the first menubaritem on keyup. This is the behavior I think we should have for alt-key presses, not toggling the menubar. This bug would conflict with the desired behavior of bug 170029 and my existing use of the alt-key to navigate and activate menu items.
(In reply to comment #1)
> Which native Vista applications have this behavior?
Internet Explorer. And Windows Media Player implements the main menu as a popup, as long as the "use classic menus" option is not chosen.
Also the file system manager.
To quote the Vista UX Guide:
"Consider hiding the menu bar if the toolbar or direct commands provide most of the commands needed by most users."
"For programs with only a few commands, having both a menu bar and a toolbar doesn’t make sense because the menu bar ends up being a redundant, inefficient version of the toolbar."
I don't think Firefox qualifies as a program with "only a few commands". Do you have any data indicating that most users rarely have to use the menu bar? Just from my own perspective I could do well without the menu bar but it'd be nice if this decision was based on more than one person's preference.
I don't see any particular reason this should be Vista exclusive. The menu mar is equally useless to everyone. Though, just hiding things without adding other ways to access the menus would be a confusing move to most users, so button(s) for popups are a must. Simply moving the menu(s) into button(s) would greatly clean up the wasted space up there.
The extension "Personal Menu" already implements this sort of thing, letting the user move the menu into a single button and adding menu buttons for bookmarks, history, etc. with the normal menu showing on alt-key. I do agree it would be nice for the basics of this to be built in, as it makes the GUI much simpler.
Even IE7 on XP hides the menu bar or at least I think it still does. I can't remember if that was changed in SP3 or not but I know there is an option to have it shown all the time.
An extra bonus of this is it would offset the screen space that the tabbar now takes up for being displayed all the time.
Just to clarify, this bug isn't about determining if we should show a menu bar by default or not in Vista. We will need to have a larger and more public discussion over that, probably in dev.apps.firefox, as opposed to just amongst the people cc'd on this bug. What this bug does cover is setting up the alt key behavior of a spring loaded menu bar, similar to several native Vista applications.
We will need a View > Menu bar toggle, similar to the current View > Status Bar in Firefox, or Organize > Layout > Menu bar in windows explorer.
>the Alt key triggers access key
>mnemonics on keydown and gives focus to the first menubaritem on keyup. This is
>the behavior I think we should have for alt-key presses
This is the behavior when the menu bar is displayed (checked in the view menu). When it is hidden (not checked in the view menu), pressing the alt key causes it to appear, mnemonics appear, and it is given focus. Sorry I wasn't clear on this behavior in the description (I wasn't in front of a vista machine when I was filling last night). The behavior is "spring loaded" in that giving focus to anything else causes it to disappear again.
*** Bug 464988 has been marked as a duplicate of this bug. ***
> We will need a View > Menu bar toggle, similar to the current View > Status Bar
> in Firefox
No you don't. The only reason the menubar (it is actually a toolbar[type="menubar"]) doesn't appear in the View > Toolbars auto-generated menu is that it doesn't have a toolbarname= attribute. Give it one and it should automatically appear on that submenu.
browser.js says if (toolbarName && type != "menubar") here.
You would also need to modify bug 477256 to use toolbar[type="menubar"][collapsed="true"] instead of [autohide="true"].
(In reply to comment #10)
> browser.js says if (toolbarName && type != "menubar") here.
> You would also need to modify bug 477256 to use
> toolbar[type="menubar"][collapsed="true"] instead of [autohide="true"].
I'll fix both things in browser.js.
Created attachment 362313 [details] [diff] [review]
This allows users to hide the menu bar on Windows. It's hidden by default on Vista.
Comment on attachment 362313 [details] [diff] [review]
Created attachment 362406 [details]
Bookmarks toolbar expands 1 px when Menu bar is set to show
(In reply to comment #13)
> (From update of attachment 362313 [details] [diff] [review])
Using the above tryserver build, the bookmarks toolbar expands 1 px when Menu bar is set to show.
1) Hit the alt key to show the menu bar
2) Go to Views->Toolbars
3) Check the Menu Bar and watch the tab bar move down a little but it is from the bookmarks toolbar expanding by one pixel.
(In reply to comment #12)
> It's hidden by default on Vista.
Please note that this is not wanted here per comment #0, comment #7 and the fact that with this change there won't be any (discoverable) way to access much functionality with just the mouse.
Neither comment 0 nor comment 7 say that we should never change the default, they just say that we shouldn't do it here. But this bug is old enough that this can be reconsidered now.
If we don't do it by default, most users won't benefit from it. And if we want to change the default, that needs to be tested extensively and sooner rather than later.
(In reply to comment #16)
> this can be reconsidered now.
Sure, but wouldn't it then be better to put some thought into how a mouse-only user will be able to print a page, zoom a page or reopen a closed tab in an obvious way as a first step of reconsideration (preferably in form of a design spec over at wiki.m.o or on m.d.a.firefox)?
>But this bug is old enough that this can be reconsidered now.
>Sure, but wouldn't it then be better to put some thought into how a mouse-only
>user will be able to print a page, zoom a page or reopen a closed tab in an
>obvious way as a first step of reconsideration (preferably in form of a design
>spec over at wiki.m.o or on m.d.a.firefox)?
Yep, we need to start seriously considering what we want to do with the menu bar (over in wiki.mozilla.org and dev.apps.firefox so that everyone can track the discussion). We should try to get a blog post up about the topic on planet as well, so that we cover every available communication channel.
Here are my very initial thoughts, copied over from the thread Dao started on dev.apps.firefox:
I think the main reason IE decided to kill the menu bar was that the
traditional desktop publishing command structure didn't really make any sense for an application that isn't based around document creation (for instance, edit-cut doesn't actually work on the selection). But they didn't remove all of the functionality, they reorganized it into two new menus, one about acting on the page, and the other about acting on the browser (which is a pretty logical distinction). What was kind of strange is that when Microsoft did this everyone thought it was awful, but when Chrome did the exact same thing, it was hailed as fantastic. (Don't forget to put on your brand goggles before evaluating an interactive design). Either way, my impression is that the two button distinction makes a lot of sense, and perhaps even more importantly, people who started with Vista will be expecting this behavior.
Introducing two new controls, a page button and tools button (or perhaps "customize" button) would give us external consistency with the other menu-less browsers on the market. We would probably want to have them in the same general area as other browsers, so that means far right of the search bar, or perhaps far right of the bookmarks toolbar. Having these two controls appear only when the menu is hidden might seem pretty odd, so perhaps have the two visible on Vista regardless of if the menu is hidden or not? The top item in the customize menu would probably need to be ("[ ] menu bar"), so frustrated users would have a quick way back to oldschool menus, assuming they poke around enough to find what they are looking for. Also we would want these two items to be removable and appear in the toolbar customization palette.
Here's how I have done it (maybe this could help dunno):
I have the menubar hidden ("Hide Menubar" ext.), but since I now could access Bookamarks and History via the alt key (not good since I mostly use mouse), I placed Bookmarks and History buttons on the left side of Bookmarksbar, and a Downloads button on the right side. Divide them from the bookmarks with a separator and you've got what I have! :)
I find this system very easy to use, since both history and bookmarks are easy to access and open in sidebar, so you can't lose them (accidental mouse click somewhere else) like with the default menu in menubar.
Created attachment 362626 [details] [diff] [review]
In order to move on with this bug quickly, here's a version that doesn't hide by default.
Alex: ping. This would be very nice to have.
Comment on attachment 362626 [details] [diff] [review]
didn't actually have time to test the patch, but approving based on described behavior
Dao, just wanted to see if you read comment #14?
Yes, I've read comment 14. Looks like a layout bug, since I don't see which front-end code would do that.
Comment on attachment 362626 [details] [diff] [review]
r=mano code wise. Given that this won't make 3.5 though, I don't see this should land at all.
(In reply to comment #25)
> (From update of attachment 362626 [details] [diff] [review])
> r=mano code wise. Given that this won't make 3.5 though, I don't see this
> should land at all.
By "not at all" I assume you meant "in the 3.5 development time frame", which is pretty much over now, so I landed this:
Using the latest hourly with changeset:
which should contain this patch, it seems the 'Menu bar' is not being hidden on Windows 7 RC x64
Nothing in the Error Console.
Is there a 'pref' that has to be twiddled ?
Sorry for the bug-spam, seems you have to 'uncheck' Menubar under View - then it works..
Yep, the menu bar is visible by default. On Vista and later, we should probably change that eventually. Feel free to file a new bug for that.
AutoHide Menu Bar does not work if the menu bar has been customized (like in the screenshot at http://picsaver.org/files/tmmzty32ewzmmze50nqm.png). To make matters even worse, it is NOT possible to move the search engine field back into the Navigation Toolbar using the "Customize..." feature.
So I won't consider this bug RESOLVED.
Created attachment 383129 [details]
Screenshot to my last comment re. customized Menu Bar.
(In reply to comment #31)
> So I won't consider this bug RESOLVED.
This should have been resolved by a depending bug.
The overall functionality of this implementation seems to work. Open issues are filed as separate bugs. So lets mark this bug as verified.
What prevents us from having a browser-chrome test for this feature on Windows?
(In reply to comment #34)
> Articles updated:
I don't see anything relevant for this bug in there.
Same question as in bug 511104 comment 4... Although this article doesn't seem to even mention that this is 3.6 material.
Which OS are you using? On the article, under "Show content customized for:" click "Windows". Content regarding the menu should be shown.
For "How to customize the toolbar" the menu bar is among the toolbars listed at the top of the article, along with Navigation Bar and Bookmarks Toolbar:.
For "Menu Reference", the menu bar item in View-->Toolbars-->* is listed.
Again, you need to have Windows selected under "Show content customized for:" to see them.
(In reply to comment #36)
> For "How to customize the toolbar" the menu bar is among the toolbars listed at
> the top of the article, along with Navigation Bar and Bookmarks Toolbar:.
Sure, but there's no word about hiding the menu bar or toolbars in general.
> For "Menu Reference", the menu bar item in View-->Toolbars-->* is listed.
Right, but it doesn't differentiate between 3.5 and 3.6.
(In reply to comment #37)
> Sure, but there's no word about hiding the menu bar or toolbars in general.
There was no mention of the menu bar previously, because it was not listed in View-->Toolbars-->*.
> Right, but it doesn't differentiate between 3.5 and 3.6.
(In reply to comment #38)
> (In reply to comment #37)
> > Sure, but there's no word about hiding the menu bar or toolbars in general.
> There was no mention of the menu bar previously, because it was not listed in
That was a mistake in the previous documentation then. The customizability doesn't depend on the View-->Toolbars listing. In fact, this still seems to be wrong for Linux.
*** Bug 555656 has been marked as a duplicate of this bug. ***