27644 - [meta] linux: Menu access using ALT key broken

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P4)

Description

[Richard Zach]

Pressing the ALT key no longer activates the menu.

Linux build 2000.02.13.08

Comment 1

[David Hyatt]

Linux no longer supports ALT keys for mnemonics.

Comment 2

[Richard Zach]

How do I get to the menu using only the keyboard then?  I thought Ctrl was for
shortcuts?

Comment 3

[David Hyatt]

Tell me how it works in 4.x.

Comment 4

[Richard Zach]

Well, it doesn't work in 4.x.  But most apps use Alt+..., e.g., Alt-F to bring
down the File menu.  Ctrl+... for shortcuts.

Comment 5

[David Hyatt]

Feature is out on Linux for beta1.  Too many bugs with various window managers 
and conflicts with the ALT key bindings currently in use.  

Comment 6

[Richard Zach]

Hm. I thought Alt for shortcuts was going away in favor of Ctrl, and the
corresponding bug was marked fixed (by you: bug 23575).  The only other problem
with Alt keys which I could find was bug 15048, also marked fixed, about
spurious Alt key events activating the menu when you switch between windows
using Alt-Tab.

But you know better than I, and I have no problem with waiting till after beta.
You agree, however, that being able to access the menu using the keyboard is a
must if we want to conform to W3C accessibility guidelines. In that case, this
should be a tracking bug, not invalid.

Comment 7

[sairuh (rarely reading bugmail)]

i agree with zach...so i'm going to reopen this as a tracking bug. paulmac, what
d'you think?

Comment 8

[Paul MacQuiddy]

sounds good

Comment 9

[David Hyatt]

4.7 doesn't support this.  This is an RFE.

Comment 10

[David Hyatt]

Removing regression from the keywords.

Comment 11

[David Hyatt]

There are on the order of 10 bugs related to this ALT problem, not to mention 
the fact that all the Linux keybindings need to be re-written to deal with CTRL 
rather than ALT.  Add to that the fact that people disagree over CTRL vs. ALT, 
and you've got a thorny situation.

I for one don't care to be involved with it.  Therefore I turned the damn 
feature off.  If someone else wants to pick this up and try to make it work, 
fine, but that person isn't going to be me.

Comment 12

[Mike Pinkerton (not reading bugmail)]

we decided to turn it off, this bug is WONTFIX.

Comment 13

[sairuh (rarely reading bugmail)]

there are still a couple bug related to this issue which are open, and should
remain open till their actually resolved: bug 24413 and bug 22515.

Comment 14

[sairuh (rarely reading bugmail)]

remaining issues covered in bug 24413 and bug 22515. verifying this one.

Comment 15

[Richard Zach]

I know I'm getting on your nerves, but this is what it says in the UAAG:

People who can't or do not use a mouse must be able to operate the user
interface with the keyboard, through voice input, a head wand, touch screen, or
other device. *Keyboard operation* of all functionalities offered through the
user interface is one of the most important aspects of user agent accessibility
on almost every platform. The keyboard is available to most users, it is widely
supported, and hooks provided for the keyboard can be used for other types of
input. [emphasis in original]

http://www.w3.org/TR/2000/PR-UAAG10-20000310/#gl-device-independence

I have a mouse, and I can live with this bug not being fixed.  I just want to
state this here for the record, lest someone in the end wants to claim that
Mozilla fully complies with W3C UAAG, because it won't.

Comment 16

[Marko Macek]

How do we reenable this? Can it be done in XUL/prefs?

I will use the windows chrome (or make my own) to make mozilla usable/not suck.

Comment 17

[sairuh (rarely reading bugmail)]

anyone able to answer Marko's question? or, better yet, perhaps a new bug (under
the "Keyboard Navigation" component) should be filed as request for this (tho'
it is more a request for info --but a good/useful one at that!). thx!

Comment 18

[saari (gone)]

Menu access using the alt key is specifically turned off for linux because: a) it 
didn't work in 4.x, and more importantly b) there were some conflicts with things 
like emacs keybindings. 

Otherwise, it should be possible to turn them on in the code; it is just #ifdef'd 
for Win32 only.

Comment 19

[Syd Logan]

Here's my two cents:

Motif Style Guide says the following:

Alt keys bring up a menu, and then hitting the nmemonic (e.g., v for paste) is 
supposed to activate the functionality. Net: Alt brings up menus.

As far as shortcuts (e.g., no menu is popped up, hitting the key combination 
just activates the functionality - I think it is open ended (except of course 
you can't use Alt), and most apps use ctrl-something (e.g., ctrl-v).

Motif is the only standard out there (at least published), and has the most 
installed apps if you consider all Unix flavors.

So for Motif: alt-foo gets menus, ctrl-foo invokes menu item commands.

Gtk+

Most apps wanting to take the documented easy way out will use GtkItemFactory to 
create menus:

static GtkItemFactory menu_items[] {
{ "/_File", NULL, NULL, 0, "<Branch>" },
{ "/File/_New", "<control>N", NewEvent, 0, NULL },
...
};

The leading underscore on the _File branch item means that the Alt-F key 
combination will cause the File menu to be popped up.
The leading underscore on the _New item, combined with the "<control>N" that 
follows means that Control-N will invoke the NewEvent() function.

I don't believe Gtk+ has a style guide -- perhaps Pavlov would be able to 
comment further -- but in its abscense I think it is totally proper to adopt an 
"Alt brings up menus" and "Cntl-foo invokes a menu item command" standard for 
all platforms (at least Windows and *nix). 

So, for gtk+ -- alt-foo once again invokes menus, and ctrl-foo is perfectly 
acceptable for menu items.

Windows

Looks like Alt-foo for menus and ctrl-foo for menu item commands here too. No 
suprise that this is similar to Motif, since Motif is documented to have been 
designed to be compatible in many ways to Presentation Manager, with which 
the Windows UI shares a legacy.

So, to me, the choice is pretty darn obvious at least, in terms of what would 
make cross platform migration easiest on users, as well as be consistent with 
the true standard UI for Unix and compatible with what Gtk+ seems to be doing.

Comment 20

[saari (gone)]

If you're trying to convince me that *nix systems have UI guidelines, I hope you 
can hear me laughing from there. Seriously, if you want to work out how to deal 
with other keybinding conflicts, go for it!

The better solution is to expose the menu access key via style so any user that 
wants alt modified keybindings and alt accessible menus, they can work out the 
conflicts as they see fit.

There is already a bug on that somewhere.

Comment 21

[Akkana Peck]

The bug on making the access keys configurable is bug 23587.  I've added a
dependency.  We've been promised that feature forever, but it never gets done
even though it's supposedly easy.  It's blocking so many of these accessability
issues that I can't believe we're still clinging to this ridiculous compiled-in
#ifdef.

Give me a break.  I'll take this bug and at least make it a pref or something
(anything so that it's not compiled in), and probably do the same thing with
23587 since evidently no one else has any interest in doing the right thing
here.

Comment 22

[Akkana Peck]

Taking bug.

Comment 23

[sairuh (rarely reading bugmail)]

adding ninoschka, as this affects her mail UI testing.

thx, akkana, for reopening and taking this bug!

Comment 24

[David Hyatt]

here's an example of the style rules to use...

menubar {
  key-equivalent: ctrl;
}

keyset {
  key-equivalent: alt;
}

Applied to a menubar, the key-equivalent property dictates what key to use to 
activate the menu.  The menubar frame would have the #ifdef code removed, and it 
would obtain the key-equivalent from the CSS3 user interface struct.  (This is 
all implemented and possible now.)

For keyset, the key-equivalent would dictate what key represents the "primary" 
key.  This would also be used for the XBL <handlers> element.

Since keysets have no display, you will need to ask jst to make this property 
obtainable using the DOM getComputedStyle method in the same way the behavior 
property is obtainable now.

XBL and the XUL key listener will then have to be modified to use 
getComputedStyle to obtain the primary key for a given keyset or handlers 
element.

That's it.

The key values that are relevant are listed below:

<cmd-key> = cmd | rcmd | lcmd
<opt-key> = opt | ropt | lopt
<ctrl-key> = ctrl | rctrl | lctrl
<shift-key> = shift | rshift | lshift
<alt-key> = alt | ralt | lalt
<meta-key> = meta | rmeta | lmeta

For more information about key-equivalent, see the CSS3 user interface spec.

Comment 25

[Matthew T (active 1999-2002)]

Apart from emacs keybindings (trying to be compatible with those would be pushing 
water uphill), what exactly are these `other keybinding conflicts' that people 
keep vaguely referring to?

The only Alt-related shortcuts (as opposed to accelerators) that Mozilla should 
be using, on any platform, are Alt+Tab and Alt+Space (reserved for use by the 
window manager), and Alt+Left/+Right (for Back and Forward). Otherwise, Alt is 
for accelerators, not for shortcuts.

Comment 26

[rubydoo123]

setting to nsbeta3+

Comment 27

[rubydoo123]

adding the brackets in the status

Comment 28

[rubydoo123]

setting priority in status whiteboard - depends on 23587

Comment 29

[Akkana Peck]

An Alt menu access key for Unix (with the accelerator modifier moved to control)
is now in, and is enabled by default (but configurable with a pref, for people
used to the old way or people who want menu access on an entirely different key,
like meta).  See bug 22515 for info on switching keys.

Comment 30

[Ninoschka Baca]

FYI: Using build 2000-08-17-08M18 on Linux. Using the ALT key activates all
menus except for View.

Comment 31

[Jeffrey Baker]

Not only does the alt key access the menubar, focus sticks tehre forever until a
mouse click or escape key.  Was this the intended behavior?  I filed a new bug
on this at bug 49401.

Comment 32

[Akkana Peck]

How weird!  I see that, too.  Probably a separate bug, though.  What happens on
Windows?  (My Windows build asserts and crashes before it gets far enough to
show the browser window.)

Comment 33

[sairuh (rarely reading bugmail)]

hokay, testing w/akkana's fix (where alt+f brings up File, alt+b Bookmarks,
essentially the top-level menus) works. vrfy using 2000.08.22.08 [comm linux],
with the *new* keybinding defaults (where Ctrl is the accelerator key).

anything new that crops up, as akkana sez, should go to separate bugs (thanks,
jwb for filing bug 49401!)