I hate it when a site opens up a popup window and hides the menubar in it. I'd like to be able to rt-click in the window and enable the menubar from the context menu.
would it be ok if we put it in the system menu? [i don't know if all os's allow this] [macos probably doesn't care]
available anywhere, doesn't matter where. Doesn't even necessarily have to be on a menu of any sort - a pref with no ui where you can specify a key combination to toggle the menubar would work.
use a user stylesheet to turn off the menubar in your build.
Ben: You misunderstood the bug. The problem isn't hiding the menu, it's showing the menu once the menu has been hidden.
Ahh Yes I like this idea immensly. It always pisses me off when I cant use Context menu's in a site. Marking NEW and putting in Browser General because I dont think its XP-Apps.
over to XPApps.
this would be useful, but i'd rather not have it in the context menu. i don't mind have having this option in one of the main menus [prolly View] and/or having a hidden pref. recommend wontfix for the context menu aspect.
I don't think an option to show the menubar would be of much help if it was in the menubar that was hidden. Trying my hand at resummarizing.
That's not meant to imply that the context menu is the right place either...
sean, heh, good point... hm, other than having a pref [hidden or otherwise], methinks this might be a candidate for a keyboard shortcut. thoughts?
If the key can just show the menu (doesn't need to actually toggle the menu), F10 would work.
i like F 10.
It might also be good to show the menubar if the user presses Alt (without pressing anything else while Alt is held down.)
Hmm, or Alt+F (or another menu mnemonic).
Matthew, comments? -> markh, who did F10. Mark, can you help out with expanding and showing menubars if these accelerators are pressed? (Doing it from C++ would be difficult; the expansion part might be impossible. Then again, if we do it from the FE, we want this behavior for all menubars. Perhaps we can do it in the binding, if the menubar gets the keypress from anywhere...)
Any mechanism offered has to be available from both the mouse and the keyboard, for accessibility reasons. `F10' won't cut it, especially on platforms where the function keys are reserved for OS use(ahem). Here's what I suggest. On Mac OS, the window.open flag to turn the menu bar off should have no effect at all. Now before standards compliance people (or people who think I'm giving the Mac special treatment) jump up and down, here's the explanation ... When authors use this flag, they're asking for a window without a menu bar *in it*. On Mac OS, that's what they always get anyway, so setting the flag should have no effect. (And indeed, on Internet Explorer for Mac OS the flag does have no effect.) On other platforms, when the menu bar is turned off, there should be an item at the bottom of *every* context menu (not just the page context menu, but also the context menus for links, images, image links, and frames), saying `Show Menu Bar'. This does the obvious thing. And yes, I know this makes the context menus even longer, but (a) it's only for popups, and (b) I have a bug to clean out the trash from the context menus already.
This isn't just about menus. This is also about scroll bars being taken away. I have had times where I needed to scroll a popup but couldn't. There should be a way to get back any part of a window's chrome that you need - be it the menu, status bar, close window, scroll bars, whatever.
Adding access keyword, as this has been discussed by the W3C User Agent Accessibilit group.
It would be cool if pressing Alt or Alt+MenuLetter would temporarily show the menubar and hide it again when a menu item has been activated or Esc pressed. It'd also be nice to permanently restore any missing chrome. As already noted, it's a bigger problem than just the menu. It's important to be able to restore (and I'd suggest toggle them off again, too) the menus, scrollbars, statusbar, toolbars, and locationbar. I believe IE4 put this context menu in the application control menu (available from Alt+Spacebar and by clicking on the icon at the left end of the titlebar). IE5 seems to have removed the capability as near as I can tell. Does this require some sort of pref to disable this capability for a kiosk mode? (I don't know if Mozilla supports a kiosk mode).
Pressing Alt shouldn't show the menu bar. This will be messy with access keys for HTML elements. If I have a field named "_L_ast Name:", I need to press Alt+L to access that field. Undoubtedly, I will press Alt before I press L. As for context menus, what about sites that have eat the oncontextmenu event so that they are never displayed?
Sorry, I should have been clearer. When I said press Alt, I meant that it should trigger the menu on the release of Alt. Just like the File menu is normally highlighted after pressing and releasing Alt. Mozilla would certainly know whether the Alt+Letter combo was for a menu or accesskey. Only a combo for the menu would need to show the menu.
Last time I checked, this would be a technique for a W3C User Agent Guideline. The user is supposed to be able to stop UI from being removed by web content.
See also bug 72001, pressing Alt+E while menu bar is collapsed makes it impossible to click on the menu after uncollapsing the menu bar.
See bug 81331, Ctrl+L should make location bar visible if it's hidden.
*** Bug 128406 has been marked as a duplicate of this bug. ***
I would prefer if the context menu item was "Show toolbars" instead of "Show menu bar". Just showing the menu bar would be awkward, and I'm usually most interested in seeing the location bar. Showing the menu bar (or other toolbars) should also turn on scrollbars if scrollbars were disabled for the window, because there's no menu item for toggling scrollbars and because the content is likely to need scrollbars once any chrome becomes visible.
*** Bug 137004 has been marked as a duplicate of this bug. ***
*** Bug 142105 has been marked as a duplicate of this bug. ***
*** Bug 144318 has been marked as a duplicate of this bug. ***
Recommend wontfix since we now have prefs (see bug 107949) to prevent scripts from hiding the menubar in the first place.
That's silly. I *do not* want all of my pop-up windows to have menubars. That would just clutter things unnecessarily. And yet, in those rare occasions when I need to get at infrequently-used commands on those popup windows (doc info, etc) I still want some way to get at them. (I agree that on a mac it might make sense to just never hide the menubar, but I'm talking about unix.)
Jamie, all of your popups wouldn't have menu bars - you would only get the menu bars if you used a command to navigate to the menubar.
Aaron Leventhal wrote: > > Jamie, all of your popups wouldn't have menu bars - you would only > get the menu bars if you used a command to navigate to the menubar. That sounds fine. But I was replying to: Jonas Jørgensen wrote: > > Recommend wontfix since we now have prefs (see bug 107949) to > prevent scripts from hiding the menubar in the first place. which I interpret as "if you ever want a popup to have a menu bar, then set a preference to make them all always have menubars", which sounds like a terrible idea.
I just looked at Bug 26353, however I'm not sure of the difference between that bug and this bug. Here's what I made out: This bug suggests adding a keyboard shortcut and context menu item, while Bug 26353 just suggests a context menu item. This bug suggests an option to restore the menubar, while Bug 26353 suggests an option to restore all the chrome items including the menubar. Should both bugs exist?
Probably, because this bug is one of two open bugs genuinely blocking bug 26353.