Closed Bug 27644 Opened 25 years ago Closed 24 years ago

[meta] linux: Menu access using ALT key broken

Categories

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

Other
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rzach, Assigned: akkzilla)

References

Details

(Keywords: meta, platform-parity, Whiteboard: [nsbeta3+][p:4])

Pressing the ALT key no longer activates the menu.

Linux build 2000.02.13.08
Keywords: regression
Linux no longer supports ALT keys for mnemonics.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
How do I get to the menu using only the keyboard then?  I thought Ctrl was for
shortcuts?
Tell me how it works in 4.x.
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.
Feature is out on Linux for beta1.  Too many bugs with various window managers 
and conflicts with the ALT key bindings currently in use.  
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.
i agree with zach...so i'm going to reopen this as a tracking bug. paulmac, what
d'you think?
Status: RESOLVED → REOPENED
Keywords: meta, pp
Hardware: PC → Other
Resolution: INVALID → ---
Summary: Menu access using ALT key broken → linux: Menu access using ALT key broken
sounds good
4.7 doesn't support this.  This is an RFE.
Status: REOPENED → ASSIGNED
Target Milestone: M18
Removing regression from the keywords.
Keywords: pp, regression
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.
Blocks: uaag
we decided to turn it off, this bug is WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WONTFIX
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.
remaining issues covered in bug 24413 and bug 22515. verifying this one.
Status: RESOLVED → VERIFIED
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.
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.

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!
Component: XP Toolkit/Widgets: Menus → Keyboard Navigation
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.
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.
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.
Depends on: 23587
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Taking bug.
Assignee: pinkerton → akkana
Status: REOPENED → NEW
Status: NEW → ASSIGNED
adding ninoschka, as this affects her mail UI testing.

thx, akkana, for reopening and taking this bug!
Keywords: pp
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.
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.
Keywords: correctness, nsbeta3
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard - depends on 23587
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
FYI: Using build 2000-08-17-08M18 on Linux. Using the ALT key activates all
menus except for View.
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.
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.)
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!)
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
Summary: linux: Menu access using ALT key broken → [meta] linux: Menu access using ALT key broken
You need to log in before you can comment on or make changes to this bug.