122479 - [mac] page access key with letters are not functional with A, Button, Textarea or Label elements

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Chris Petersen]

Build: 2002-01-29-08
Platform: Mac OS X and OS 9
Expected Results: Access key should function on a Anchor, Label, and Button
element in a HTML or XHTML document.

What I got: Assigned "key" is not processed which is specified for the element

Steps to reproduce: 

1) Go to any of these three test cases:

http://mozilla.org/quality/browser/standards/html/a_accesskey.html

http://mozilla.org/quality/browser/standards/xhtml/transitional/button_accesskey.xml

http://mozilla.org/quality/browser/standards/xhtml/transitional/label_accesskey.xml,


2) Press the Control key with the assigned "key".

3) Access key is ignored.

Comment 1

[Chris Petersen]

Textarea element with accesskey attribute has this problem too.

Comment 2

[Chris Petersen]

Attachment: Textarea with accesskey attribute

Comment 3

[Chris Petersen]

Basically, looks like keydown events are not being processed.

Comment 4

[Chris Petersen]

Adding nsbeta1

Comment 5

[Kevin McCluskey (gone)]

Works fine on WINXP using 2002020512 build.

Comment 6

[Kevin McCluskey (gone)]

Reassigning to Don.
Marking nsbeta1+

Comment 7

[Chris Petersen]

Yes, this is a Mac only issue.

Comment 8

[Kevin McCluskey (gone)]

nsbeta1+

Comment 9

[Kevin McCluskey (gone)]

Set milestone to Moz1.0

Comment 10

[Syd Logan]

Aaron, can you please add some information regarding this and section 508?

Comment 11

[Aaron Leventhal]

This isn't a Section 508 issue, although it is a major accessibility bug.
Perhaps it should be marked nsbeta1- for now.

The reason is, you can still use any of the interactive elements by tabbing to
them. Section 508 only requires that you be able to use the keyboard, not that
it be convenient.

Comment 12

[Kevin McCluskey (gone)]

nsbeta1-, topembed-, based on comment #11.

Comment 13

[dcone (gone)]

Attachment: Patch to reduce the brightness of the color instead of hardcoded gray.

Comment 14

[Chris Petersen]

Remove minus from nsbeta1. This is a problem on the mac only that needs to be
resolved. This is working in NS 6.2.3.

Comment 15

[Kevin McCluskey (gone)]

Comment on attachment 77944 [details] [diff] [review]
Patch to reduce the brightness of the color instead of hardcoded gray.

It looks like this patch was posted to the  wrong bug.

Comment 16

[Jesse Ruderman]

*** Bug 94376 has been marked as a duplicate of this bug. ***

Comment 17

[Jesse Ruderman]

*** Bug 149202 has been marked as a duplicate of this bug. ***

Comment 18

[Kevin McCluskey (gone)]

nsbeta1+

Comment 19

[Greg K.]

*** Bug 168721 has been marked as a duplicate of this bug. ***

Comment 20

[Greg K.]

Per comment 3, is this blocked by bug 44259, bug 111335, or bug 148130?

Comment 21

[Kathleen :Brade]

This is not blocked by bug 44259.  That bug is about shifted keyUp and keyDown
events.  

Are accesskey events triggered by keyup, keypress, or keydown?

This particular bug may be blocked by 111335 but I am unfamiliar with that bug
since I hadn't seen it until just now.

Comment 22

[Henri Sivonen (:hsivonen)]

*** Bug 175469 has been marked as a duplicate of this bug. ***

Comment 23

[Garrett Smith]

*** Bug 185765 has been marked as a duplicate of this bug. ***

Comment 24

[sairuh (rarely reading bugmail)]

->jkeiser, but reassign as needed.

Comment 25

[Simon Fraser [no longer active]]

The OS-level 'Full keyboard access' might interfere with this, since it steals
some Control-letter combinations, including Control-C.

I'll take this, since it's Mac-only.

Comment 26

[Greg K.]

(Is there a related bug somewhere about enabling _command_ accesskeys in chrome
dialogs?)

Comment 27

[sairuh (rarely reading bugmail)]

per comment 25: try changing the key to function keys (ie, if previously set to
control+letter keys) in the Keyboard system pref, and see if this still occurs.

Comment 28

[Garrett Smith]

Oddly, Accesskey works with numbers.

This works:
<a href='/' accesskey='1'>Home</a>

This doesn't:
<a href='/' accesskey='h'>Home</a>

Comment 29

[Kathleen :Brade]

in widget/src/mac/nsMacEventHandler.cpp, a control-A keypress event goes through
HandleUKeyEvent which explicitly passes false to the aConvertChar parameter (so
the charcode is probably decimal 1 instead of character 'A')

From what I can tell, no letter combinations work.

Comment 30

[Kathleen :Brade]

This bug was not fixed with the checkin to bug 184549 (which fixed bug 148130
and bug 111335).  As I stated in previous comment, this has to do with character
conversion and "Control" key.

Comment 31

[Kathleen :Brade]

Attachment: patch to address controlkey-letter combinations

This patch fixes all of the testcases I saw in this bug.
I also tested these things and they all continue to work:
  control-space to open context menu in browser and composer
  typing in text widgets and composer
  opening new windows (mail compose and composer)

Comment 32

[Kathleen :Brade]

Comment on attachment 124067 [details] [diff] [review]
patch to address controlkey-letter combinations

note: I also tested typing Japanese and found no regression there either.

Comment 33

[Simon Fraser [no longer active]]

->brade

Comment 34

[Simon Fraser [no longer active]]

Comment on attachment 124067 [details] [diff] [review]
patch to address controlkey-letter combinations

Looks reasonable

Comment 35

[sairuh (rarely reading bugmail)]

test cases from bug 148130:

http://bugzilla.mozilla.org/attachment.cgi?id=85839&action=view

http://bugzilla.mozilla.org/attachment.cgi?id=94030&action=view

Comment 36

[Brian Ryner (not reading)]

Comment on attachment 124067 [details] [diff] [review]
patch to address controlkey-letter combinations

>+      // translation already occurred for the string passed to this method.
>+      if (keyEvent.isControl && keyEvent.charCode <= 26)       

One suggestion, here maybe you could use   keyEvent.charCode <= 'Z'
just for clarity.

sr=bryner with or without that change.

Comment 37

[Kathleen :Brade]

fix checked into trunk; will see how it goes and consider asking for 1.4 if no
regressions

Comment 38

[sairuh (rarely reading bugmail)]

could we get this into the 1.4 branch?

i'll test this out on a trunk build soon.

Comment 39

[sairuh (rarely reading bugmail)]

ran some tests using today's trunk build (comm, 2003.05.29.08 on 10.2.6).

i had saved a copy of jesse's test at
http://hopey.mcom.com/tests/page-accesskeys-jesse.html

all the access keys worked there, except the ones (ctrl+W, ctrl+T) for which my
OS settings (Keyboard sys pref) took precendence.

the tests in comment 35 also appear to work.

i'm going to mark this as fixed on the trunk. if we could check this into the
branch, please add the fixed1.4 keyword. thanks!

Comment 40

[Kathleen :Brade]

Comment on attachment 124067 [details] [diff] [review]
patch to address controlkey-letter combinations

requesting permission to land this mac-specific fix on the 1.4branch.  It
allows accesskeys to work.  Sairuh has tested  the trunk (where it already
landed) and found no problems.

Comment 41

[Asa Dotzler [:asa]]

Comment on attachment 124067 [details] [diff] [review]
patch to address controlkey-letter combinations

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 42

[(not reading, please use [e-mail] instead)]

I can land this on the 1.4 branch, if you need me to.

Comment 43

[Samir Gehani]

a=adt to land this on the 1.4 branch.

Comment 44

[(not reading, please use [e-mail] instead)]

fixed also landed on 1.4 branch

Comment 45

[sairuh (rarely reading bugmail)]

vrfy'd on branch, 2003.06.03.05-1.4 (OS X 10.2.6).