Last Comment Bug 51940 - [Mac] ACCESSKEY should use "Control" instead of "Command"
: [Mac] ACCESSKEY should use "Control" instead of "Command"
Status: VERIFIED FIXED
: pp
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: PowerPC All
: P3 normal (vote)
: ---
Assigned To: rods (gone)
: gerardok
Mentors:
http://slip/projects/marvin/html/a_ac...
Depends on: Accesskey-XUL
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-08 16:57 PDT by Loco
Modified: 2002-02-22 01:08 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Loco 2000-09-08 16:57:23 PDT
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.
Comment 1 Kevin McCluskey (gone) 2000-09-14 13:45:19 PDT
Dividing up Claytons bugs to triage
Comment 2 rods (gone) 2000-09-15 06:22:07 PDT
brade, joki, and myself went back and forth on this, deferring to Simon. the fix 
is easy and low risk.
Comment 3 Simon Fraser 2000-09-15 12:14:24 PDT
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)?
Comment 4 Matthew Paul Thomas 2000-09-16 00:49:26 PDT
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.
Comment 5 Matthew Paul Thomas 2000-09-17 15:51:59 PDT
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).
Comment 6 rods (gone) 2000-09-18 07:02:30 PDT
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
Comment 7 Simon Fraser 2000-09-18 11:21:50 PDT
Control key is fine with me. Sounds like this bug is fixed then, no?
Comment 8 Mike Pinkerton (not reading bugmail) 2000-09-19 10:15:27 PDT
yeah, joki and i put that in last week....didn't know there was a bug already.
Comment 9 Loco 2000-09-20 14:36:02 PDT
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.
Comment 10 Mike Pinkerton (not reading bugmail) 2000-09-20 14:41:06 PDT
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? 
Comment 11 Loco 2000-09-20 14:47:49 PDT
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.
Comment 12 Matthew Paul Thomas 2000-09-20 18:23:56 PDT
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.
Comment 13 Mike Pinkerton (not reading bugmail) 2000-09-20 18:47:31 PDT
win32Mozilla does not fail (1) anymore, joki and i fixed the bug.
Comment 14 Antti Näyhä 2000-09-26 01:07:14 PDT
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. :-)
Comment 15 Antti Näyhä 2000-10-13 01:38:34 PDT
FYI: the discussed remaining issue is filed as bug 55020.
Comment 16 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-09-05 10:46:22 PDT
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Note You need to log in before you can comment on or make changes to this bug.