37660 - [Win] <alt>+F then <left> should go to the system menu

Status: NEW

(Core :: XUL, defect, P3)

Description

[timeless]

With normal windows apps, pressing alt-space brings up the system menu [eg, 
Netscape 4]. With apps that manually draw the menu bar, alt [walk] generally 
lost fails to reach the system menu [eg ie] -- HOWEVER alt-space works on ie.

[alt-space]
Expected Behavior: system menu.
Mozilla Behavior: nothing.

[menu bar down, left arrow beyond file menu]
Expected Behavior: File, then system menu, then last menu [QA, then Debug, then 
Help, ...]
Mozilla Behavior: File, then last menu [QA, then Debug, then Help, ...]

tested win32-talkback 2000042808 [seen in various milestones]

Possibly worth noting, if you don't have a mouse or accessibility, the only way 
to do resizes [iirc] is alt-space.  23936 therefore is hindered even further by 
this bug.

Comment 1

[Sean Richardson]

The ALT+SPACE problem is bug 19328, "[Windows] ALT+SPACEBAR is not activating 
control menu" ... there is also the related bug 23445, "[Windows] ALT,SPACEBAR 
is not activating control menu".

Keeping this bug for the problem with the control menu not being part of the 
menu navigation sequence for [left] and [right] -arrow navigation when the menus
are down. In NN 4.x, the control menu is activated between the Help and File
menu, keying rightwards -- but not if the menu name is highlighted without
the menu being dropped down. The same applies to Notepad, Explorer, etc.

So ALT+letter, or ALT+[down], followed by repeats of either [right] or [left]
should eventually reach the control menu, but if only the menu name is 
highlighted, the control menu is left out of the sequence.

Adjusting summary from "[Win32] pressing alt-space does nothing; <alt> then 
<left> should walk to the system menu [unless this is a consistency and because 
you can't do it on non win32 ...] -- either way, alt-space is a must." to
"[Win32] <alt>+letter then <left> should go to the system menu"; marking 4xp
for Windows -- those who *rely* on keyboard navigation may miss this.

Matthew, would this be inapplicable for MacOS? XWindows also has a control menu;
would this be more useful or more an annoyance there?

Comment 2

[Blake Ross]

Although I'm not quite sure if this is as high priority as alt+space.  After 
all, even IE doesn't select/dropdown the command menu when keying left/right.

It's also worth mentioning that pressing alt once, then [left arrow], then 
[space] or [down arrow] should bring down the command menu, as it does in 
Notepad, etc.  (same should go for the [right arrow] key if you're over the QA 
menu)  Right now, pressing alt, then left will cycle back to the last menu 
(currently, QA), which is also how IE behaves.

Comment 3

[Matthew T (active 1999-2002)]

MacOS doesn't, and shouldn't, have control menus for windows. (Command menus are 
something else entirely ...)

Some X window managers may have a control menu, but I would be surprised if {Alt, 
Left} activated it, since it's outside the control of the app.

Therefore, this is Windows only.

Comment 4

[saari (gone)]

CC'ing hyatt. M19

Comment 5

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 6

[sairuh (rarely reading bugmail)]

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

Comment 7

[saari (gone)]

Would be nice to fix for mozilla 1.0

Comment 8

[selmer (gone)]

Nominating nsdogfood: we should honor OS shortcuts (are there other similar
problems?)

Comment 9

[:deanis74]

This code drops down the system menu of a window.  It's important to use 
PostMessage, not SendMessage.

// activate the system menu
PostMessage(hWnd, WM_SYSCOMMAND, SC_KEYMENU, 0);
PostMessage(hWnd, WM_KEYDOWN, VK_DOWN, 1);  // 1 = repeat count
PostMessage(hWnd, WM_KEYUP, VK_DOWN, 1 + (1 << 31));  // 1 << 31 = key released

All that's needed is to hook this into the order of menus in the main menu bar.

Comment 10

[:deanis74]

The tough part of this interaction is not activating the system menu, but 
"jumping off" the system menu once it's active and left or right is pressed.  
Right now we don't do that.  I'm not really sure how we _could_ do that.  And if 
we can't do that, then we shouldn't do the other part.  It would be really 
annoying to press Alt+F, then left twice to go to Help, but realize that you're 
stuck on the system menu and there's no apparent way to get off.

Comment 11

[timeless]

at worst, i think it's possible to ask windows what's in the system menu (apps 
and os may change it, so you shouldn't just assume), if we did this, then we 
could emulate the system menu using the xul menu objects which should be able 
to handle left/right.

Comment 12

[:deanis74]

Well of course we could do that.  Makes sense to me, and wouldn't be too 
difficult to interrogate the system menu.

Comment 13

[Sean Richardson]

Emulating the windows control menu in XUL is the right way to solve this
problem, but there are implications. 
 1. Since there should be only one control menu, and it belongs in the titlebar:
 2. Unless the control menu can be turned on and off independently of the 
    MS-titlebar, the entire titlebar would need to be generated in XUL, 
    complete with the minimize, (un)maximize, and close controls at the 
    right end, the title itself, *and*
 3. All Mozilla windows on MS-Windows would need the MS-titlebar turned off.

Issues: 
 A. Can the control menu be interrogated when it isn't displayed?
 B. If the titlebar is done in XUL, it makes sense to solve the bug 2426
    / bug 9449 problem (bad title display if window manager local/encoding does     
    not match page locale/encoding) once and for all by having Mozilla, not
    the WM, display the title, making the WM's i18n status irrelevant.
    Yes, this would be an XP fix to an XP problem; enabling a fix to the
    Windows-only control menu problem would almost be a side-effect.
 C. Replacing the MS-titlebar with a XUL-titlebar would be a big change
    that would require UI loving, pulling out code that communicates the 
    title to the WM, multiple module owner acceptance, and  some serious 
    regression monitoring.

Given all that, doing the control menu in XUL is still the right solution,
but the needed work can't all fit in this bug ;-|.

Comment 14

[timeless]

Sean Richardson: you missed my point, and your requests don't belong here.

My premise is that 
a) we can ask windows what items are in the system menu
b) render them using xul
c) trap the windows show menu event

When I say xul, i don't mean hard coded xul, i mean xul dom where the os 
provides us w/ the content.

Comment 15

[:deanis74]

Sean, I think that you've hit on all of the long-term issues.  Eventually, I'd
like to see a theme applied to the entire window, including the title bar.  But
there are definitely some larger issues to solve first.  But I wonder if we
can't do what Timeless suggests in the interim.

On the other side of things, should we worry about this until we get full-window
skinability in?  Right now we behave exactly like IE 4+ and  Explorer in
Win2000.  I haven't heard too much complaining about not having this
functionality in those apps.

Comment 16

[:deanis74]

We don't need to get as in-depth as Sean suggested.  The display of the system 
menu can be can traped using:

   case WM_INITMENUPOPUP:
     if (HIWORD(lParam) == TRUE)  // fSystemMenu == TRUE
       SendMessage(hWnd, WM_CANCELMODE, 0, 0);

As long as the System Menu is visible, we can interrogate it.  Once it's hidden 
I haven't found a way to interrogate it.  But once we're doing the entire menu 
in XUL, maybe we can let the chrome dictate whether there's a system menu and, 
if so, its contents.

Comment 17

[:deanis74]

*** Bug 13042 has been marked as a duplicate of this bug. ***

Comment 18

[timeless]

*** Bug 87803 has been marked as a duplicate of this bug. ***

Comment 19

[:deanis74]

Note to self: write some code to interrogate the system menu for its contents.

Comment 20

[saari (gone)]

->hyatt for xpmenu behavior

Comment 21

[saari (gone)]

*** Bug 118662 has been marked as a duplicate of this bug. ***

Comment 22

[:deanis74]

Attachment: Sample code that enumerates the system menu for a window and displays a messagebox describing each item.

(Hey, at least it's been less than a year since I told myself to write it!)

Comment 23

[:deanis74]

OK I've figured out how to get the system menu into the left/right menu
navigation sequence on the menu bar.

1. Left/Right to move to the system menu

Hook the ShowSystemMenu() function (attachment 74059 [details] [diff] [review] of bug 86770) up to
nsMenuBarListener.cpp.  Instead of wrapping around, for example, to the first
menu when the last item on the menu bar is active and right is pressed, call
ShowSystemMenu().

2. Left/Right when the system menu is active

I never knew about the WM_NEXTMENU message until about 1/2 an hour ago.  This
makes things a lot easier.  We can use it to determine if the user's moving off
of the system menu quite easily.  Here's some code sample (pardon the extra
braces, it's C not C++).  Only the "Leaving System Menu" half is relevant, I
left the "Selecting System Menu" code in there for completeness.

    case WM_NEXTMENU: {
      MDINEXTMENU *mnm;
      char outString[255];

      strcpy(outString, "WM_NEXTMENU: ");

      mnm = (MDINEXTMENU *) lParam;

      //gSysMenu determined after the window is created
      // using GetSystemMenu(hWnd, FALSE)
      if (mnm->hmenuIn == gSysMenu) {  
        strcat(outString, "Leaving System Menu -- Select");
        if (wParam == VK_LEFT)
          strcat(outString, " LAST");
        else
          strcat(outString, " FIRST");
        if (!gHasNativeMenuBar)
          // (made up variable)
          // if there isn't a native menu bar, close the system menu
          PostMessage(hWnd, WM_CANCELMODE, 0, 0);
      } else {
        strcat(outString, "Selecting System Menu -- Selected from");
        if (wParam == VK_LEFT)
          strcat(outString, " FIRST");
        else
          strcat(outString, " LAST");
      }

      strcat(outString, " menu item on menu bar\n");
      OutputDebugString(outString);
    }
    break;

Comment 24

[timeless]

how about a nice patch for mozilla ;-), please :)

Comment 25

[Daniel Wang]

Can anyone verify if this can even be done? I tested MS Office 97 and
MSIE5 on Windows 98 and found that neither permits navigation to system
menu from the (custom) menu bar. I suspect the problem to be that
WM_NEXTMENU is never sent by the system menu (event necessary to
navigate *back* to the menu bar)

If this is not doable, please change summary to XUL implementation
of system menu. Make sure right click on title bar will also show the
(custom?) system menu. (Is it a good idea to hack system menu, even?)

Comment 26

[:deanis74]

This can still be done, yes.  The reason that Office and IE don't do it is
because they don't use standard Windows menus.  Check out Notepad, it still has
this behavior.

Comment 27

[:deanis74]

Is this still wanted?  If so, I'll push for sr= on bug 86770 and then code this up.

Comment 28

[Vaclav Dvorak]

Sure it's wanted. It's standard Windows behaviour. :-) (But not very important
even to MS, it seems.)

Comment 29

[Vaclav Dvorak]

See also bug 154540 for another consequence of having two menubars (a native
Windows one and a XUL one). Sorry for not mentioning it in the previous comment.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

*** Bug 357155 has been marked as a duplicate of this bug. ***

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 4 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 32

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.