Closed Bug 1153577 Opened 5 years ago Closed 4 years ago

Users should be able to hide the menubar and show it with the ALT key

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

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)

(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.
Attached patch Patch v1.0 Proposed fix (obsolete) — Splinter Review
Attachment #8591698 - Flags: review?(neil)
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+
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.
>>-    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)
(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.)
"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.
> "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 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.
>>-                         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)
Depends on: 1170264
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.
> 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)
Blocks: 1170264
No longer depends on: 1170264
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+
http://hg.mozilla.org/comm-central/rev/6e1cf8c8ef70
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.39
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)
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 → ---
Attached image screenshot comparison
Screenshot shows UBUNTU Unity Dash search <https://help.ubuntu.com/12.04/ubuntu-help/unity-dash-intro.html> after alt-key
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.
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.
Related: "Bug 1224231 - Mention "Hide Menu Bar" feature in Help"
See Also: → 1224231
Depends on: 1224907
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
See Also: → 1224907
(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.
(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 "?
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).
(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.)
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.
I am on windows 8.1U1, with ribbon explorer disabled, and the menu indeed opens with F10 in explorer, notepad, and calculator.
Bug 1224907 is fixed. Closing.
Status: REOPENED → RESOLVED
Closed: 5 years ago4 years ago
Resolution: --- → FIXED
@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.