Closed
Bug 1153577
Opened 9 years ago
Closed 8 years ago
Users should be able to hide the menubar and show it with the ALT key
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(seamonkey2.39 fixed)
RESOLVED
FIXED
seamonkey2.39
Tracking | Status | |
---|---|---|
seamonkey2.39 | --- | fixed |
People
(Reporter: philip.chee, Assigned: philip.chee)
References
(Blocks 1 open bug)
Details
User Story
Feature for Browser, Address Book and e-mail-client: This feature adds a new pulldown item "Menu Bar" to menu 'View → Show/Hide'. If "Menu Bar" is hidden (removed checkmark) normally the Menu Bar is invisible, but reappears when <alt> key will be pressed.
Attachments
(2 files, 4 obsolete files)
22.16 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
574.83 KB,
image/png
|
Details |
(From Bug 456535 comment #0) > 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.
Assignee | ||
Comment 1•9 years ago
|
||
Attachment #8591698 -
Flags: review?(neil)
Comment 2•9 years ago
|
||
Comment on attachment 8591698 [details] [diff] [review] Patch v1.0 Proposed fix >- var i; >- for (i = 0; i < els.length; ++i) { >+ for (let i = 0; i < els.length; ++i) { Why this change? >- if (aShow) >- els[i].removeAttribute("autohide"); >- else >+ if (!aShow) { >+ els[i].setAttribute("saved-autohide", >+ els[i].getAttribute("autohide")); > els[i].setAttribute("autohide", "true"); >+ } >+ else { >+ this.restoreAttribute(els[i], "autohide"); >+ } Nit: switch back to if (aShow) i.e. if (aShow) this.restoreAttribute(els[i], "autohide"); else { ... } >diff --git a/suite/browser/navigator.xul b/suite/browser/navigator.xul What about other windows? Speaking of Windows, what about Mac? >+ var hidingAttribute = type == "menubar" ? "autohide" : "hidden"; Nit: Call this the toggleAttribute etc.
Attachment #8591698 -
Flags: review?(neil) → feedback+
Comment 3•9 years ago
|
||
So, for the Mac, there are two possibilities: 1. Use script to skip the menubar toggle menuitem on the Mac 2. Use overlays to overlay the menubar attributes on Windows and Linux The overlay has the slight advantage that the locale string doesn't have to be duplicated for each window.
Assignee | ||
Comment 4•9 years ago
|
||
>>- var i; >>- for (i = 0; i < els.length; ++i) { >>+ for (let i = 0; i < els.length; ++i) { > Why this change? It triggered my OCD. I've reverted this change. > Nit: switch back to if (aShow) i.e. > if (aShow) > this.restoreAttribute(els[i], "autohide"); > else { Fixed. >>+ var hidingAttribute = type == "menubar" ? "autohide" : "hidden"; > Nit: Call this the toggleAttribute etc. Fixed. > So, for the Mac, there are two possibilities: > 1. Use script to skip the menubar toggle menuitem on the Mac > 2. Use overlays to overlay the menubar attributes on Windows and Linux > The overlay has the slight advantage that the locale string doesn't have to be duplicated for each window. I've decided to use overlays. > +++ b/suite/common/communicator.css .... > +toolbar[type="menubar"][autohide="true"] > +{ > + -moz-binding: url("chrome://global/content/bindings/toolbar.xml#toolbar-menubar-autohide"); > + overflow: hidden; Do you think we should have a grippy-menubar-autohide? > +++ b/suite/common/history/history.xul Not sure if it's necessary to autohide the menubar in the history and bookmark managers. > + <toolbar id="placesToolbar" > + type="menubar"> > + <menubar id="history-menu" > + grippytooltiptext="&menuBar.tooltip;"> Wrap the menubar with a toolbar id="placesToolbar" so that I can use the same overlay as bookmarks.xul. > + <toolbar class="chromeclass-toolbar" > + id="placesSearchToolbar" > + align="center" > + grippytooltiptext="&searchBar.tooltip;"> > + <textbox id="search-box" Rename the existing "placesToolbar" to "placesSearchToolbar" Do you think the searchbox should be moved to the menu-toolbar and the separate toolbar be removed? The Bookmarks manager has the searchbox in the menu toolbar. I think we should be consistent here.
Attachment #8591698 -
Attachment is obsolete: true
Attachment #8595392 -
Flags: review?(neil)
Comment 5•9 years ago
|
||
(Answering this one because it's an easy answer) (In reply to Philip Chee from comment #4) > Do you think we should have a grippy-menubar-autohide? No, it would be impossible to click the grippy. (If you full-screen the window, then activate the menu bar, clicking on the navbar grippy just dismisses the menubar.)
Comment 6•9 years ago
|
||
"e" conflicts with Search Bar in the Mail and News window. (In reply to Philip Chee from comment #4) > Not sure if it's necessary to autohide the menubar in the history and > bookmark managers. The menuitem does look lonely... > Do you think the searchbox should be moved to the menu-toolbar and the > separate toolbar be removed? The Bookmarks manager has the searchbox in the > menu toolbar. I think we should be consistent here. I can't remember the history (!) but that's something for a separate bug.
Assignee | ||
Comment 7•9 years ago
|
||
> "e" conflicts with Search Bar in the Mail and News window. Fixed. > (In reply to Philip Chee from comment #4) >> Not sure if it's necessary to autohide the menubar in the history and >> bookmark managers. > The menuitem does look lonely... I've moved the menu item directly into the top level popup in both cases.
Attachment #8595392 -
Attachment is obsolete: true
Attachment #8595392 -
Flags: review?(neil)
Attachment #8600384 -
Flags: review?(neil)
Comment 8•9 years ago
|
||
Comment on attachment 8600384 [details] [diff] [review] Patch v3.0 Use "n" as the access key in MailNews >- oncommand="ViewMenu.setSortColumn(event.target.column, null);"> >+ oncommand="ViewMenu.setSortColumn(event.target.column, null); event.stopPropagation();"> Why this change? >+ <menu id="menu_View"> >+ <menupopup id="viewPopup" >+ onpopupshowing="onViewToolbarsPopupShowing(event)" >+ oncommand="onViewToolbarCommand(event);"> >+ <menuseparator id="toolbarmode-sep"/> >+ </menupopup> >+ </menu> OK, this does look a bit better this way. > #ifdef XP_WIN32 >-* content/communicator/platformCommunicatorOverlay.xul (win/platformCommunicatorOverlay.xul) >+ content/communicator/platformCommunicatorOverlay.xul (win/platformCommunicatorOverlay.xul) [Might as well change this to XP_WIN while you're here.] > var menusep = document.getElementById("toolbarmode-sep"); > > var menubar = toolbox.getElementsByAttribute("type", "menubar").item(0); > if (!menubar || !toolbars.length) { >- menusep.hidden = true; >+ if (menusep) >+ menusep.hidden = true; > return; > } >- menusep.hidden = false; >+ if (menusep) >+ menusep.hidden = false; Is this still needed? >+<!ENTITY menubarCmd.label "Menu Bar"> >+<!ENTITY menubarCmd.accesskey "e"> >+<!ENTITY mailMenubarCmd.accesskey "n"> I don't really like this, I'd prefer some other solution if you wouldn't mind.
Assignee | ||
Comment 9•9 years ago
|
||
>>- oncommand="ViewMenu.setSortColumn(event.target.column, null);"> >>+ oncommand="ViewMenu.setSortColumn(event.target.column, null); event.stopPropagation();"> > Why this change? I didn't want the event to propagate up to the "onViewToolbarCommand(event);" further up. >> #ifdef XP_WIN32 >>-* content/communicator/platformCommunicatorOverlay.xul (win/platformCommunicatorOverlay.xul) >>+ content/communicator/platformCommunicatorOverlay.xul (win/platformCommunicatorOverlay.xul) > [Might as well change this to XP_WIN while you're here.] Fixed. >> var menusep = document.getElementById("toolbarmode-sep"); >> >> var menubar = toolbox.getElementsByAttribute("type", "menubar").item(0); >> if (!menubar || !toolbars.length) { >>- menusep.hidden = true; >>+ if (menusep) >>+ menusep.hidden = true; >> return; >> } >>- menusep.hidden = false; >>+ if (menusep) >>+ menusep.hidden = false; > Is this still needed? Not currently, but just in case some future use needs this. >>+<!ENTITY menubarCmd.label "Menu Bar"> >>+<!ENTITY menubarCmd.accesskey "e"> >>+<!ENTITY mailMenubarCmd.accesskey "n"> > I don't really like this, I'd prefer some other solution if you wouldn't mind. Thinking... I've created a new file (or files) platformMailnewsOverlay.dtd and using that for the mailnews menubar.
Attachment #8600384 -
Attachment is obsolete: true
Attachment #8600384 -
Flags: review?(neil)
Attachment #8602982 -
Flags: review?(neil)
Comment 10•9 years ago
|
||
I had a chat with IanN last night and we decided that we'd prefer a solution that keeps the same access key in all windows for the "Menu Bar" item.
Assignee | ||
Comment 11•9 years ago
|
||
> I had a chat with IanN last night and we decided that we'd prefer a
> solution that keeps the same access key in all windows for the "Menu Bar"
> item.
/Sigh/ I've changed the access key for "Search Bar" from "e" to "a".
Attachment #8602982 -
Attachment is obsolete: true
Attachment #8602982 -
Flags: review?(neil)
Attachment #8622585 -
Flags: review?(neil)
Assignee | ||
Updated•9 years ago
|
Comment 12•9 years ago
|
||
Comment on attachment 8622585 [details] [diff] [review] Patch v5.0 Change access key for the Search Bar. (Sorry for the delay.) Sigh, bug 1161802 broke our full screen handler, but there's a slightly quirky interaction between full screen and the View Menu Bar menuitem; if you hide the menubar, go full screen, then show the menubar, then exit full screen, then it hides again. (Other toolbars simply don't show in full screen.) [Bah, Composer still doesn't have customisable toolbars.]
Attachment #8622585 -
Flags: review?(neil) → review+
Assignee | ||
Comment 13•9 years ago
|
||
http://hg.mozilla.org/comm-central/rev/6e1cf8c8ef70
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox40:
affected → ---
status-seamonkey2.39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.39
Comment 14•9 years ago
|
||
Fix VERIFIED with SeaMonkey German 2.39b1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area) Gecko/20100101 Firefox/42.0 Build 20151028234211 (Classic Theme) on German WIN7 64bit. New Pulldown item "Hide Menu bar" is available for Browser, e-Mail client and Address-Book, works fine. Not available for Composer. After having unchecked the Menu-Bar visibility, the feature with <alt> key also will work with older versions, installed in parallel. But in those older versions there is no way to make Menu bar visible again.
User Story: (updated)
Comment 15•9 years ago
|
||
a) Feature "Menu Bar ON" did not conflict with b) <alt+anykey> during my WIN tests DID conflict with shortcuts containing alt>, because Menu bar becomes switched OFF. But I don't think that this is a real problem, any next action would have switched off Menu Bar. c) Feature does NOT AT ALL work with German SeaMonkey 2.41a1 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Build 20151029003002 (Classic Theme) on VirtualBox Ubuntu 14: <alt> will bring up a Linux Command line instead of activating SM Menu bar. So I reopen this one for now. Please feel free to shift this problem to a new Bug report if you think that that would be a better way.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 16•9 years ago
|
||
Screenshot shows UBUNTU Unity Dash search <https://help.ubuntu.com/12.04/ubuntu-help/unity-dash-intro.html> after alt-key
Comment 17•9 years ago
|
||
This might be more a UBUNTU / Unity problem than a SM feature problem. But most time the FF solution works and brings up a menu bar with <alt>. My Linux knowledge is not sufficient for more investigation.
Comment 18•9 years ago
|
||
In my UBUNTU / Unity environment <alt+shorcut key> will bring up the menu bar and open the related pulldown from the Menu Bar item. But <alt> to make visible hidden menu bar does not work at all.
Comment 19•9 years ago
|
||
Related: "Bug 1224231 - Mention "Hide Menu Bar" feature in Help"
See Also: → 1224231
Comment 20•8 years ago
|
||
May be as a rewult of the fix for this one, we now have "Bug 1232093 - Find Bar missing in Bookmarks Manager". Really related?
See Also: → 1232093
Comment 21•8 years ago
|
||
(In reply to Rainer Bielefeld from comment #18) > In my UBUNTU / Unity environment <alt+shorcut key> will bring up the menu > bar and open the related pulldown from the Menu Bar item. But <alt> to make > visible hidden menu bar does not work at all. I see the same thing on OpenSUSE with KDE4. However, the stated keyboard shortcut for the menu bar is not ALT but F10 instead (the latter also works on Windows). I couldn't find the originating bug report, http://mxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/common/help/shortcuts.xhtml#222 clearly states that so in the Help documentation.
Comment 22•8 years ago
|
||
(In reply to rsx11m from comment #21) > I see the same thing on OpenSUSE with KDE4. However, the stated keyboard > shortcut for the menu bar is not ALT but F10 instead ... I can reproduce your observations, but <f10> is worrying: * UBUNTU: an undocumented <alt+f> or similar, shows File-Menu likd <alt+f> (what IS in accordance with Help "Open Main Menu (switches to the first drop-down menu at the top of the window)" * WIN: brings up Menu bar if necessary and highlghts 'File' menu Item WITHOUT showing menu (what is NOT in accordance with "Open Main Menu (switches to the first drop-down menu at the top of the window)" This discussion might be better for "Bug 1224231 - Mention new "Hide Menu Bar" feature in Help "?
Comment 23•8 years ago
|
||
Yes, I've commented there already. The question is if the behavior of F10 instead of ALT is intended on Linux or if it is actually a bug somewhere that should be fixed (and if not, this bug here can probably be closed as fixed again).
Comment 24•8 years ago
|
||
(In reply to rsx11m from comment #23) > Yes, I've commented there already. The question is if the behavior of F10 > instead of ALT is intended on Linux or if it is actually a bug somewhere > that should be fixed (and if not, this bug here can probably be closed as > fixed again). I'm not surprised by the fact that F10 opens the menus. When I use it on L64 SeaMonkey 2.43a1 en-us timestamped 2016-01-09_00:30:01 I see the File menu, then the arrow keys allow me to navigate it (the right-arrow will select the submenu if there is one, or go to the next menu otherwise, while the left arrow cycles leftwards from menu to menu). This looks like "expected behaviour" to me. If it isn't standard on current Windows software, then I think it was once standard, maybe on XP or W3. Where do I have documentation about that? Hmm, let me see… Ah, here is one tidbit of information from the (very complete) Vim help: «On Win32 and with GTK, <F10> will select the menu, unless it has been remapped.» (Vim "loves" backward compatibility, meaning «if it ain't broke it don't fix it», and OTOH on Linux it offers a choice of GUIs, including none, selectable at compile-time, but the default [if nothing else is --enable'd] is currently GTK2 if configure finds it.)
Comment 25•8 years ago
|
||
P.S. I'm on openSUSE Leap 42.1, and Alt alone (i.e. "press and release Alt") does nothing, but the en-US menus are Alt+F = File, Alt+E = Edit, Alt+V = View, Alt+G = Go, Alt+B = Bookmarks, Alt+T = Tools, Alt+A = Tabs (from an extension), Alt+W = Window, Alt+U = Debug, Alt+Q = QA and Alt+H = Help.
Comment 26•8 years ago
|
||
I am on windows 8.1U1, with ribbon explorer disabled, and the menu indeed opens with F10 in explorer, notepad, and calculator.
Assignee | ||
Comment 27•8 years ago
|
||
Bug 1224907 is fixed. Closing.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → FIXED
Comment 28•8 years ago
|
||
@neil: The lack of this feature in composer depends on unfixed "Bug 606683 - Allow customization of toolbars in Composer and formatting toolbar in MailNews Composition"?
You need to log in
before you can comment on or make changes to this bug.
Description
•