332365 - Improper ctrl+alt+accessKey behaviour on remapped keyboard

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

If I set an access key of u, say, on a button, then the normal behaviour is that if I press alt+u, the button should be activated whether or not ctrl and whether or not shift are also pressed.  And this works fine on my US keyboard.

However, if I have a non us keyboard, alt+ctrl+key (with or without shift) may be mapped to a printing character, such as € or ú (euro symbol or u with an accent).  In this case, when I am in a text field or text area, I would expect the character to be rendered in that element.  Or, for that matter, a file, password, and even select element may make use of the character.  And this is working, too.

However, in other cases (where any printing character would simply be ignored), if there is an access key assigned to an element/elements, one such element should be activated (or at least receive focus).  This is not working as expected.

I could not find a workaround for this.  But in my experimentation, I found that if I put up an alert on a keydown event, where alt+ctrl+u (with or without the shift) was pressed, then the accessKey was recognized.  But I didn't find a way to achieve the same thing without the access key.

Csaba Gabor from Vienna


Reproducible: Always

Steps to Reproduce:
To ovserve this behaviour, you need to find a character on your keyboard where holding down the alt+ctrl+thatKey will produce a printing character on your Windows system and then assign thatKey as the accessKey to the button.  If ctrl+alt+u is already printing for you, then you can use the attachment as is.

In the attachment, if you move the focus to the dummy link or checkbox and press ctrl(+shift)+alt+u then nothing will happen (item 1).  If you check the unblock checkbox, then an alert will come up when you press ctrl(+shift)+alt+u and subsequently the button will fire (item 2).

Note, that if you pop up the alert while the focus is in a text element (by uncommenting the line:
evt.target.type=="text" ||
), although the character will print, the button will also be activated.  Also, note that the alert being popped up (what I called unblocking) will only happen if the unblocked checkbox is checked.



Expected Results:  
1.  If alt+ctrl(+shift)+char is pressed when focus is not on an element that would respond to that character, then if one or more elements have an accessKey of char, one such element should be activated/focused.

2.  Putting up an alert should not affect the outcome of the accessKey behaviour.

Comment 1

[Csaba Gabor]

Attachment: Fixed (ctrl+alt+u) accessKey demo page

Basic demonstration.  Perhaps a better test page would allow the user to set the access key to assign to the button, in case a tester has a key other than alt+ctrl+u set as a printing character.

Comment 2

[Simon Bünzli]

Accesskeys are currently triggered by all Alt, Alt+Shift, Ctrl+Alt and Ctrl+Alt+Shift key combinations - which renders useless an awful lot of possible shortcuts (useless in the sense that you're never sure whether they'll have any undesired side effects).

*Advertisement* My patch to bug 340902 would nicely fix this.

Comment 3

[Csaba Gabor]

However, in some instances, this type of behaviour (where the access key is triggered regardless of whether ctrl/shift are held down) is precisely what a web page author wants because it enhances/gives different meaning to the same control.

Just as a for example with a non FF situation, Alt+tab on Windows cycles through the various apps.  Alt+Shift+tab cycles in the reverse order.  Not necessary, but useful.

While this type of appoach does hog keys, it may be what is desired.  I use it to offer refined control in a few places.

Comment 4

[Simon Bünzli]

Marking this bug FIXED as a consequence of fixing bug 340902.

(In reply to comment #3)
> However, in some instances, this type of behaviour (where the access key is
> triggered regardless of whether ctrl/shift are held down) is precisely what a
> web page author wants because it enhances/gives different meaning to the same
> control.

That's not how accesskeys (in the strict sense of the word) work. You're rather talking about keyboard shortcuts which continue to work as usual.