Closed Bug 51940 Opened 24 years ago Closed 24 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: 24 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.