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)
Tracking
()
VERIFIED
FIXED
M18
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
Reporter | ||
Updated•25 years ago
|
Keywords: regression
Comment 1•25 years ago
|
||
Linux no longer supports ALT keys for mnemonics.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•25 years ago
|
||
How do I get to the menu using only the keyboard then? I thought Ctrl was for shortcuts?
Comment 3•25 years ago
|
||
Tell me how it works in 4.x.
Reporter | ||
Comment 4•25 years ago
|
||
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•25 years ago
|
||
Feature is out on Linux for beta1. Too many bugs with various window managers and conflicts with the ALT key bindings currently in use.
Reporter | ||
Comment 6•25 years ago
|
||
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•25 years ago
|
||
i agree with zach...so i'm going to reopen this as a tracking bug. paulmac, what d'you think?
Comment 8•25 years ago
|
||
sounds good
Comment 9•25 years ago
|
||
4.7 doesn't support this. This is an RFE.
Status: REOPENED → ASSIGNED
Target Milestone: M18
Comment 11•25 years ago
|
||
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•24 years ago
|
||
we decided to turn it off, this bug is WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Comment 13•24 years ago
|
||
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•24 years ago
|
||
remaining issues covered in bug 24413 and bug 22515. verifying this one.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 15•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Comment 18•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Comment 21•24 years ago
|
||
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 → ---
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 23•24 years ago
|
||
adding ninoschka, as this affects her mail UI testing. thx, akkana, for reopening and taking this bug!
Keywords: pp
Comment 24•24 years ago
|
||
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•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Keywords: correctness,
nsbeta3
Comment 28•24 years ago
|
||
setting priority in status whiteboard - depends on 23587
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
Assignee | ||
Comment 29•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 30•24 years ago
|
||
FYI: Using build 2000-08-17-08M18 on Linux. Using the ALT key activates all menus except for View.
Comment 31•24 years ago
|
||
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.
Assignee | ||
Comment 32•24 years ago
|
||
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•24 years ago
|
||
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
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•5 years ago
|
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.
Description
•