View Full Version : 1.0a3 grid keyboard support problems on FF and Opera

15 Mar 2007, 5:06 AM
hi all!

after adding an input type=text to the pagingtoolbar for searching i noticed a very irritating problem.

somehow the mappings for e.UP and e.RIGHT seem to break the "(" and "&" characters on a german keyboard.

( -> SHIFT+8
& -> SHIFT+6

instead of being able to type these characters the grid selectionmodel thinks i'm pressing the up and right keys.

this occurs on FF and Opera, IE 6+7 seem to work fine. no idea what Safari does.

you can easily test it on

by just trying to type into the default page-number input
i'm not sure if or how this bug shows on other keyboard layouts. needs to be tested.

15 Mar 2007, 6:30 AM
I can see the problem on my laptop with different language settings (then Shift-6 and Shift-8 might be Shift-7 and Shift-9 though), but I can't reconstruct it on my normal PC (full 102 Keyboard). My guess is that you are using a laptop too?

15 Mar 2007, 6:37 AM
actually i'm on a laptop, but with a full keyboard attached.
and it happens on normal pc's as well, tested on 1 pc and 2 different laptops.
but all have german keyboard layouts.

19 Mar 2007, 5:59 AM
Can I ask what keys are reported for up and right? Same keys?

19 Mar 2007, 7:03 AM
somehow it differs when using keypress or keydown

Ext.fly('query').on('keypress', function(e) {

when pressing SHIFT+8 for the "(" i get keycode 40 which is wrong, thats the keycode of cursor up or SHIFT+8(on number block)
when pressing SHIFT+6 for the "&" i get keycode 38 which is wrong, thats the keycode of cursor right or SHIFT+6(on number block)

Ext.fly('query').on('keydown', function(e) {

when pressing SHIFT+8 for the "(" i get keycode 56 and lots of repeating 16 (for shift)
when pressing SHIFT+6 for the "&" i get keycode 54 and lots of repeating 16 (for shift)

19 Mar 2007, 7:12 AM
What do you get for the arrows with keypress?

19 Mar 2007, 7:24 AM
wait i mixed s.th. up with the keycodes on the number block these are the same as the cursor one. so ignore that

but anyways:

38 => UP
39 => RIGHT
40 => DOWN
37 => LEFT

but that should be the same in whatever language layout

3 Apr 2007, 3:27 AM
i noticed that the same bug prevents typing "(" in a ComboBox

thats SHIFT+8 on the german keyboard

and again only in FF and Opera, in IE 6+7 it works.

(tested in current 1.0b1)

3 Apr 2007, 10:30 AM
Hey neongrau,

I'm not sure how I can test this to develop a workaround (if it can be worked around). One thing you may try is overriding the Ext.KeyNav function which hooks the events and change it to always use keydown? The will break repeated key firing but should at least make it function.

3 Apr 2007, 10:55 AM
the keypress instead of keydown sounds like an idea, but isn't that weird?
could it be a bug in FF that is causing the wrong keycodes to be returned?

3 Apr 2007, 11:11 AM
just did a quick test. and it seems (but beware i haven't yet looked at Ext.KeyNav)
that there is a mixup with keyCode and charCode on the keypress event.

with "keypress" FF reports for SHIFT+8:
keyCode: 0 and charCode: 40

with "keydown" FF reports for SHIFT+8:
keyCode: 57 and charCode: 0

so when using the charCode instead of keyCode the keypress gets wrongfully mapped to keyCode 40 which is in fact cursor down?!?

3 Apr 2007, 11:15 AM
So the down arrow and shift+8 return the same thing? :-?

3 Apr 2007, 9:44 PM
yes, it looks like Ext.KeyNav returns the charCode as keyCode which should be different.

4 Apr 2007, 1:54 AM
hi jack!

when looking at Ext.EventObjectImpl.prototype i see that getKey and getCharCode always try to fall back to the other value.

you can't do that since they have different meanings, keyCode is the id of the key while charCode is the reference to the typed character. for example:

String.fromCharCode(40) is "("
String.fromCharCode(38) is "&"

that must not be taken as a keyCode!!!

i tried it with the "|| .." parts commented out:

Ext.EventObjectImpl.prototype {
getCharCode : function(){
return this.charCode;// || this.keyCode;

getKey : function(){
var k = this.keyCode;// || this.charCode;
return Ext.isSafari ? (safariKeys[k] || k) : k;

this results in Firefox working as expected, nothing seems to break in IE, shouldn't have any effect to Safari. Opera will still do it wrong but not better or worse then before.

4 Apr 2007, 4:05 PM
The reason for that is FF w/ keypress in many cases does not return a keyCode, only charCode.

If you scroll to the bottom of this page:


There is a nice key tester. If you check keypress and keydown and use FF, you will see what I mean.

However there is probably a range of keys that we can filter (like 37-40, 8, 13, etc). If you can help determine what keys are going wrong on your keyboard, I would happy to add that filter in.


4 Apr 2007, 10:09 PM
it's probably not that easy. since it differs not only from brwoser to browser (from what i read only gecko browsers and opera (partly) seem to support charCode). it also differs by the event listened for.

for example: the SHIFT+8, with onkeydown it will only be report keycodes (shift, 8, and the combo), while onkeypress will resemble the generated character that was supposed to be printed into a textbox or s.th. as charCode. so it'd be necessary to decide what element has the focus and will this element accept the insertion of the char. and only if it does accept
the char the custom mapped action should be allowed to get cancelled.

but i see the differences in all browsers with that are a huge mess to deal with :(