Closed Bug 51940 Opened 25 years ago Closed 25 years ago

[Mac] ACCESSKEY should use "Control" instead of "Command"

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzillaabuse, Assigned: rods)

References

(
URL
)

Details

(Keywords: platform-parity)

Build ID: 2000-09-04-08 Happens OS: MacOS 9.0.4 Doesn't Happen OS: N/A Actual Results: Nothing. ACCESSKEY is confused with "Command" combinations: Command + C is Copy, for instance. Expected Results: ACCESSKEY should be using a non-conflicting key on the Mac keyboard-like Control, or if not available, Option. Reason for Severity: N/A Reproducible? Yeppers. Steps to reproduce: Code: (changed from ACCESSKEY = "C" to "A" since it illustrates what happens better - Command + A is "Select All") <html> </head> <title>HTML Functional -- ANCHOR - ACCESSKEY</title> </head> <body> The ACCESSKEY attribute has been assigned a value of "A". In this case, pressing ALT-A should take the user to the <a accesskey="A" href="http:// home.netscape.com"> linked document</a> </body> </html> There is no easy solution to this. If we continue with ACCCESSKEY using the Command key, we'll have to disable the other commands-like Copy, Paste, etc. Not good. If we do nothing, the ACCESSKEY, and Customer, will not know exactly what is going on. I understand that changing the ACCESSKEY on Macs to "Control" could be a bit of a nightmare, but its the only really plausible solution.
Keywords: pp
Summary: ACCESSKEY should use "Control" key instead of "Command" key on Mac → [Mac] ACCESSKEY should use "Control" instead of "Command"
Dividing up Claytons bugs to triage
Assignee: clayton → rods
brade, joki, and myself went back and forth on this, deferring to Simon. the fix is easy and low risk.
Status: NEW → ASSIGNED
I agree that using command is bad, because of conflicts with menu shortcuts. What do other platforms do? How do they avoid conflicts (since isn't Control the menu shortcut key on Windows)?
Teehee, this is fun. Before ACCESSKEY, the world looked like this: Windows/X Mac OS ------------------------------------------------------------------------------ Ctrl keyboard shortcuts user macros (hardly used in practice) Cmd -- [1] keyboard shortcuts [2] dialog control accelerators (sometimes) Alt/Option [3] menu accelerators type alternate characters [4] dialog control accelerators [1] and [2] didn't conflict with each other on Mac OS, solely through the application programmer making sure that common shortcuts like Cmd+W, Cmd+Z, Cmd+X, Cmd+C, and Cmd+V weren't used for other controls in the dialog. Such careful design is obviously not possible with ACCESSKEY, where you're at the whim of the page author. [3] and [4] didn't conflict with each other on Windows, because they occurred in different situations: windows with menus (document windows, mainly) didn't have dialog controls, and windows with dialog controls (i.e. dialogs) didn't have menus (except in stupid cases like the Find: File utility). Then along comes the W3C, and says that HTML controls should be able to have ACCESSKEYs, even though by far the most common user agents where ACCESSKEYs would be useful -- that is, Web browsers -- also have menus. Gee, thanks a lot, guys. So, in IE 5 for Windows, the world looks like this: Windows ------------------------------------------------------------------------------ Ctrl activate keyboard shortcuts Alt,{key} activate menu accelerators Alt+{key} select (but don't activate) ACCESSKEYed item; or activate menu accelerator if there is no ACCESSKEY for {key} in the document This is messy, but it works, kinda. Alt can't activate an ACCESSKEYed control, it can only select it -- to guard against the possibility that the user was expecting it to activate a menu instead. Luckily Mac OS is free from the need for such contortions, in that it has a (nearly) completely unused modifier key at its disposal: Control. The Macintosh HIGs say that Control is reserved for `shortcut key sequences that the user defines using a macro-key facility'. And I think using it for `shortcut key sequences that the document author defines using an HTML facility' would be quite within the spirit (if not the letter) of those guidelines.
One thing I forgot to mention: even though Mac Mozilla can use the Control key solely for accesskeys, it should still only give focus to the ACCESSKEYed item (for activating with the Enter key), and not actually activate it. There are two reasons for this. The first is to prevent users who use both Windows and Mac OS from inadvertently activating links etc when using Mac OS. And the second is that the page author might define two or more items with the same ACCESSKEY, so I should be able to use Ctrl+{key} to cycle between those items (rather than just activating the first one).
Windows uses the ALT key which is the same key it uses for menus. Acording to the source code we are using the control key on the Mac: #ifdef XP_MAC // (pinkerton, joki, saari) IE5 for mac uses Control for access keys. The HTML4 spec // suggests to use command on mac, but this really sucks (imagine someone having a "q" // as an access key and not letting you quit the app!). As a result, we've made a // command decision 1 day before tree lockdown to change it to the control key. PRBool isSpecialAccessKeyDown = keyEvent->isControl; #else PRBool isSpecialAccessKeyDown = keyEvent->isAlt; #endif
Control key is fine with me. Sounds like this bug is fixed then, no?
yeah, joki and i put that in last week....didn't know there was a bug already.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Seems fixed to me in MacOS 9.0.4 build 09-19-09. One last question remains, however: ------- Additional Comments From Matthew Thomas 2000-09-17 15:51 ------- One thing I forgot to mention: even though Mac Mozilla can use the Control key solely for accesskeys, it should still only give focus to the ACCESSKEYed item (for activating with the Enter key), and not actually activate it. --------------------------- Are we doing this? If so, its not entirely fixed, but I'll verify it for now. Up to you-I'm just happy the darn things works well.
Status: RESOLVED → VERIFIED
win32Mozilla and macIE both cause onclick to fire on a button with an accesskey. you're saying macMozilla should only focus the widget, not click it?
My take is that accesskey should actually click on the item, but I wanted Matthew to get some attention:). At least we should address the issue (i.e. Is it a valid request? Yes/No), I guess. Also, placing dependency on bug 959, which curiously enough is still not fixed. Could you give me some insight as to <A ACCESSKEY> works but not <AREA ACCESKEY>? I'm kinda lost there. I guessed that if you fixed one, you'd fix the other-or at least get that much closer to a total solution.
Depends on: Accesskey-XUL
With accesskey, because the contents of the page is out of your control, you cannot be sure that you will produce the desired result if: (1) you will produce the expected result if there is a menu in the browser with the same accesskey as the link/button (2) there is more than one item in the page with the same accesskey. That's why activating an accesskey should give focus to the accesskeyed item (and if there are more than one with the same accesskey, cycle between them), *not* activate it -- so the user can confirm or change the action before it happens. > win32Mozilla and macIE both cause onclick to fire on a button with an > accesskey. If that is correct, then win32mozilla fails both (1) and (2); macIE fails (2). So that is dataloss at most, and sanityloss at least.
win32Mozilla does not fail (1) anymore, joki and i fixed the bug.
Um, winMozilla *is* still failing (1) since we're triggering 'onclick' whenever an access key is pressed. I agree with Matthew that we should only focus instead. I'll file another bug about that - unless Matthew beats me to it. :-)
FYI: the discussed remaining issue is filed as bug 55020.
OS: All
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
QA Contact: bugzilla → gerardok
You need to log in before you can comment on or make changes to this bug.