On the Linux 2000-08-17-13 build, striking the alt key focuses the menubar forever. The only way to un-focus the menubar is to click with the mouse, or use the escape key. In past builds, and the 4.x product, striking the alt key by itself did nothing. I propose that the old behavior is better and that the new behavior is a nuisance. Also the current behavior is not consistent with other gtk applications.

Cc'ing self because I'm curious what the model is supposed to be.

Jeffrey, what is the behavior for other GTK applications? On Windows, Alt the first time gives focus to the first menu (i.e. the `File' menu), Alt the second time returns focus to its original position. Is this what GTK does as well?

In GNOME and GTK applications, the ALT key alone has no effect. Using alt+<letter> will raise the menu with that letter, such as alt+f for the file menu or alt+e for edit. The current mozilla behavior is not consistent with anything that I have seen.

akkana, d'you mind owning this for now? (if not, feel free to hand it back to don, the default owner). nominating for beta3, to see if we can work out some sort of useful resolution by then. :)

This is standard on Windows. Don't know about Linux...cc dean Why is this such a problem anyways?

This is not the behavior on any known platform. Read the report again.

Let me be more clear here: the desired behavior on X is for the alt key, by itself, to do nothing whatsoever. I have never seen any X application that responded to the alt key by moving the input focus. This is very undesirable.

Bleh. Please read this carefully: Windows is a platform, this is the behavior on windows. Subject reformed because permanent does not accurately describe the scenario descrbied. Question: Does pressing alt twice revert focus to whereever it was prior to pressing it? I'm not proposing won't fix, but I like being able to completely walk the menus, and people who have problems w/ accessibility do too. While i'm asking silly linux questions... what happens if you do: alt-f;esc? [pick your favorite test suite, but include: mozilla, netscape4, gfm, kfm, gmc, xemacs] Also, please explain why you think the behavior you want is an enhancement (marking bug as enhancement because I think this is a silly bug that should be treated as Enhacement resolvable wontfix).

None of you are reading the original bug report, regardless of your propensity to belittle me. Please make sure you understand this 100% before you post a reply. In Linux Mozilla of recent days: 1) You strike alt 2) Mozilla moves the focus to the menubar. This is the windows behavior, not consistent with X applications 3) You strike the alt key again 4) Mozilla does NOTHING You see, it is step 4 that differentiates the current behavior from that found on windows. If you read the original report that I made, you would have seen the line that "the only way to unfocus the menubar is to click with the mouse, or use the escape key" On windows, hitting alt focuses the menu bar, and hitting alt again moves the focus back to wherever it was from. The current Linux Mozilla does *not* do this. That is why the observed behavior is definitly a bug. If anyone can name a platform where the behavior described in steps 1-4 is the behavior of the majority of applications, I will send them $1000. No kidding. To answer timeless' direct questions: 1) No, hitting alt twice does not move the focus back. I explained this already. 2) In unix netscape4, alt-f raises the "find in page dialog". For all GTK and some Motif applications, alt-f raises and focuses the "File" menu, if such exists. This is the desired behavior IMHO. Esc unfocuses the menu in all cases. None of the apps that I tested have the alt-focuses-menubar behavior, except for KDE in it's default configuration. But KDE has the windows behavior, where alt toggles the menubar focus. In Mozilla, alt does not toggle. It simply sticks. You last question has been ignored because this is not an enhancement request. It is an obvious and very bad misfeature, which can be traced to very recent changes in the X event handling code.

Then there's two bugs here: that pressing ALT in the first place focuses the menubar, and then that pressing it again doesn't unfocus it. Since the latter issue will be fixed if the former is, this bug really only covers the former. And the former is the standard behavior on Windows. Hence the confusion... Updating summary.

Blake the question is, does Alt focus the menu bar in any window manager under Linux? If not, then it would be a simple #ifdef so that the Alt keypress processing in the menu bar listener doesn't process under Linux/Unix. If that's the desired behavior under all of X, then we've got an easy fix here. If some window managers allow Alt to focus the menu bar and others don't, then we have to pick one to support. If we decide that Alt shouldn't focus the menu bar under _any_ *nix, assign this to me and I'll fix it up.

My intention at this point: Find the place where the menubar is focused on a single press of the menu access key, and make that disablable (ui.key.menuAccessKeyFocuses = PR_FALSE or something like that).

Me likey. Would this then be defaulted differently when creating a new user profile, depending on the platform? Akkana, here's the code chunk you're looking for: http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuBarListener.cpp#112 (the menu bar isn't focused until the access key is released)

Here's a patch which I think should fix the problem. The default is to make alt light up the menubar on windows, but not on any other platforms. Someone please test this and review it -- I don't see the original problem with my kde window manager (alt works even when mozilla has menu focus) so I can't do a good test, but I do no longer see the greyness in the menubar when I hit alt.

Oh, and thanks, Dean, for pointing out where I needed to make the fix. That definitely saved me some time!

Looks good to me from a code point of view. I don't have time to compile it up right now, but there's no reason it shouldn't do the job. Oh, and Akkana you're welcome. About the only part of Mozilla that I know fairly well is menus.

Akk, check in the patch and let reporter check it out

I checked in the fix -- but then I talked to Hyatt and I have a much better fix on the way in a few days. Leaving this open, but in the meantime you should have the workaround.

Show off! Can't you fix just one bug at a time??

Yeah, really. You're putting all of us "only-fix-one-bug-at-a-time" losers to shame.

Fix is in! Life is beautiful. :-)

Oops -- it looked like this was fixed, because the File menu no longer highlights when you press alt by itself, but the focus is still in the menubar (press e and you'll get the edit menu, for example). Reopening.

Found the place I'd missed, which dp pointed out. Now if I type alt by itself, followed by f by itself, the file menu does not come up, and if I alt-tab in kde, windows change their stacking order. Let me know if there are any remaining problems.

And also, if you type alt+f, the file menu does not appear. All menu accels are broken. Reopening as we still don't have the right fix.

Leaving this one. Looks like Akkana has it relatively under control.

Wow, the bug that wouldn't die -- too many ways of invoking this functionality. Okay, I have a better fix now, I think (awaiting review).

Checked in. Crossing my fingers that this solves all the problems ...

using opt comm bits 2000.09.01.06 on linux, using both the newmod and classic skins: * hitting the Alt key by itself doesn't doing anything. is this expected behavior? (whatever expected means in unix ;) on win32, Alt brings focus to the File menu label (tho' doesn't dropdown the menu) --but that *is* another operating system. * holding down Alt+F drops down the File menu (Alt+B the bookmarks menu, Alt+V the view menu, and so forth). once the menu is dropped down, all i need to do is hit a menu access key *without holding down Alt* to access a given item. (eg, hit P for Print, print dialog appears.) gonna vrfy this, unless what am seeing isn't the expected behavior...

Recent builds are behaving the way I expect them to. Confirm your verify :)

I have the horrible feeling that by implementing this differently from Windows, we have just made it impossible for anyone to use an ACCESSKEY which is the same as the mnemonic for a menu ... See my 2000-09-16 comment in bug 51940. Can someone on Linux please try <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8945> on a trunk build, and verify that you can: (a) access the QA menu using the keyboard (b) activate the `quux' button using the keyboard. If not, then we have an accessibility problem (not to mention a potential one-click-shopping problem), and this bug will have to be reopened and implemented in a way that's inconsistent with GTK. :-/

mpt: i can get the menu but not the button on bug 8945. How do you propose that the button should be activated? I should be able to tab to it, but I cannot. In Windows, you cannot have a button and a menu with the same accel key, so I don't see why it should work on Unix. In any case it's a losing cause on Unix: my window manager or other software may very well intercept whatever you think is the "right" keystroke.

As I said in bug 51940, the way IE for Windows does it is this: * {Alt+key} selects the accesskey in the page -- e.g. {Alt+Q} selects the `quux' button in <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8945>) * {Alt,key} selects the menu -- e.g. {Alt,Q} opens the `QA' menu when <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8945> is open. I think Mozilla should do the same thing on both Windows and Linux, because there doesn't seem to be any other way of preventing clashes between menu mnemonics and page accesskeys on a PC keyboard. However, if that is implemented, then pressing Alt by itself *must* activate the menu bar, otherwise {Alt,key} won't work. That would unfortunately break consistency with GTK, but I don't see any other way of doing it (it would seem to be an accessibility bug of GTK anyway). Your originally reported nuisance could be solved by making a second press of Alt unfocus the menu bar, as it does on Windows.

It still wouldn't be an accessibility blocker, since users who want the Windows-style behavior of focusing the menubar on alt-by-itself can always turn on the pref ui.key.menuAccessKeyFocuses. It's off by default on Unix because so many people on linux were running into problems with their windowmanagers. Re the test: when I first load the page, alt-Q focuses the Quux button. If I hit tab, then press alt-Q again, I get the QA menu. I don't seem to be able to tab back into the content area afterward so that alt-Q will get the quux menu back, though, and there's no visual indication while I'm tabbing as to where the focus is (that would be a separate bug, of course).

In a quick little test on Windows, I recall similar behavior. If I clicked on a blank area in the document and pressed Alt+Q, I could get back to the Quux button.

I have two alternative approaches a) tell w3c that they're crazy and that html should not do this. b) offer a key to toggle between app bindings and document bindings We'll ignore a. Why b. Most users build habits, they expect certain things, alt-f;x = quit. If a web page captures alt-f at some point farther done the screen and that launches