Seem like no way to get keycode from KeyDownHandler, KeyUpHandler

866 views
Skip to first unread message

AB

unread,
Feb 13, 2010, 7:29:00 PM2/13/10
to Google Web Toolkit
The newish event handler system seems designed to prevent getting a
keycode from the KeyDown and KeyUp events? Does anyone know the
reasoning behind this?
This creates a problem. For example, in IE, if one wants to detect
autorepeats of a non char key like an uparrow, you only get it on a
KeyDown event (see http://unixpapa.com/js/key.html ). Since the
KeyPress does not get repeats (in IE for arrow keys), I need an
KeyDown event handler that knows they key that was hit (maybe i could
write enough logic to first sense the keypress, then remember that
keycode,...)

Jim Douglas

unread,
Feb 13, 2010, 8:03:06 PM2/13/10
to Google Web Toolkit
You should start by taking a quick look at the source code to see
exactly what value GWT returns for KeyPressEvent.getCharCode(); it
might be different from what you expect.

http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/user/src/com/google/gwt/event/dom/client/KeyPressEvent.java&q=keypressevent%20package:http://google-web-toolkit%5C.googlecode%5C.com&sa=N&cd=1&ct=rc

You can add a tiny bit of JSNI code to get anything you need from the
key events. For example, I do this as one part of a check for special
keys:

public void onKeyPress(KeyPressEvent event)
{
char c = event.getCharCode();
char which = getWhich(event.getNativeEvent());
if (isOpera() && c == m_keyDown && (c == KEY_HOME ||
c == KEY_END ||
c == KEY_INSERT ||
c == KEY_DELETE))
which = 0; // I hate Opera. See: http://unixpapa.com/js/key.html


protected native char getWhich(NativeEvent e)/*-{
return e.which;
}-*/;

protected native char getCharCode(NativeEvent e)/*-{
return e.charCode;
}-*/;

protected native char getKeyCode(NativeEvent e)/*-{
return e.keyCode;
}-*/;


On Feb 13, 4:29 pm, AB <abere...@drillinginfo.com> wrote:
> The newish event handler system seems designed to prevent getting a
> keycode from the KeyDown and KeyUp events?  Does anyone know the
> reasoning behind this?
> This creates a problem. For example, in IE, if one wants to detect
> autorepeats of a non char key like an uparrow, you only get it on a

> KeyDown event (seehttp://unixpapa.com/js/key.html). Since the

Thomas Broyer

unread,
Feb 14, 2010, 7:15:53 AM2/14/10
to Google Web Toolkit

On Feb 14, 1:29 am, AB <abere...@drillinginfo.com> wrote:
> The newish event handler system seems designed to prevent getting a
> keycode from the KeyDown and KeyUp events?

You mean a char code? or KeyPress event?

> Does anyone know the reasoning behind this?

Key down/up events are designed for keys, not chars, contrary to
keypress.

> This creates a problem. For example, in IE, if one wants to detect
> autorepeats of a non char key like an uparrow, you only get it on a

> KeyDown event (seehttp://unixpapa.com/js/key.html). Since the


> KeyPress does not get repeats (in IE for arrow keys), I need an
> KeyDown event handler that knows they key that was hit (maybe i could
> write enough logic to first sense the keypress, then remember that
> keycode,...)

OK, so you seem to really be talking about KeyDown/KeyUp and key code
(arrow keys).

Have you looked at the events' getNativeKeyCode() method and the
KeyCodes class?

Jim Douglas

unread,
Feb 14, 2010, 1:31:52 PM2/14/10
to Google Web Toolkit
Thomas,

Alan is writing low level code that needs to deal correctly with key
repeats in all browsers. Sadly, this requires writing browser-
specific code that does some detailed parsing of the keydown and
keypress events.

This article provides some good background:

http://unixpapa.com/js/key.html

And the associated test page is a convenient way to see what events a
browser fires for each key:

http://unixpapa.com/js/testkey.html

One simple example:

Open that page in Firefox.
Press the right arrow key long enough to trigger key-repeat.
Note the stream of events.
Do the same in Chrome; note the different stream of events.

PPK's notes are out of date, but still useful:

http://www.quirksmode.org/js/keys.html

Bottom line: Writing low level JavaScript code to manage keystrokes
is a challenge. The GWT documentation notes that there are no
coherent browser standards in this area:

http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/event/dom/client/KeyEvent.html
"The native keyboard events are somewhat a mess (http://
www.quirksmode.org/js/keys.html), we do some trivial normalization
here, but do not attempt any complex patching, so user be warned."

Thomas Broyer

unread,
Feb 15, 2010, 9:31:51 AM2/15/10
to Google Web Toolkit

On Feb 14, 7:31 pm, Jim Douglas <jdoug...@basis.com> wrote:
> Thomas,
>
> Alan is writing low level code that needs to deal correctly with key
> repeats in all browsers.

OK, sorry. The real issue is with repeats then, and more specifically
Opera. But Alan titled his message "get keycode from KeyDownHandler,
KeyUpHandler" and talks about IE; and there I see absolutely no issue
at all.

> Sadly, this requires writing browser-
> specific code that does some detailed parsing of the keydown and
> keypress events.

Only in Opera actually, because it only repeats KeyPress events
(whereas it shouldn't even fire them in the first place in case of
arrow keys which do not generate text)

> This article provides some good background:
>
> http://unixpapa.com/js/key.html
>
> And the associated test page is a convenient way to see what events a
> browser fires for each key:
>
> http://unixpapa.com/js/testkey.html
>
> One simple example:
>
> Open that page in Firefox.
> Press the right arrow key long enough to trigger key-repeat.
> Note the stream of events.
> Do the same in Chrome; note the different stream of events.

Firefox only adds KeyPress events. The issue is Opera here, and *only*
Opera.

> PPK's notes are out of date, but still useful:
>
> http://www.quirksmode.org/js/keys.html

They do not deal with repeats.

> Bottom line:  Writing low level JavaScript code to manage keystrokes
> is a challenge.  The GWT documentation notes that there are no
> coherent browser standards in this area:
>

> http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/g...
> "The native keyboard events are somewhat a mess (http://www.quirksmode.org/js/keys.html), we do some trivial normalization


> here, but do not attempt any complex patching, so user be warned."

See:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3753
http://groups.google.fr/group/Google-Web-Toolkit-Contributors/t/e705905e2cc78408
and http://gwt-code-reviews.appspot.com/142801/show

So, as I said, the only issue here is Opera (Firefox behavior is a
PITA too, but workable). So, either:
- do yourself a favor, don't support repeats in Opera (they'll
probably change behavior sooner or later given that DOM3EVENTS lead
towards IE/Safari behavior [1])
- use deferred binding to special-case Opera (store
KeyDownEvent::getNativeKeyCode and check repeats in KeyPress *instead*
of KeyDown while KeyPressEvent::getCharCode() ==
KeyDownEvent::getNativeKeyCode(); because in current GWT versions,
KeyPressEvent::getCharCode will give you the arrow "codes", in both
Opera and Firefox BTW); which would be an almost equivalent to the
code you proposed, just far simpler:

private int keyCode;

public void onKeyDown(KeyDownEvent event) {
keyCode = event.getNativeKeyCode();
// given that registering/unregistering event handlers in Opera is
very fast
// you could even only register the KeyPressHandler when keyCode
needs
// repeats-processing!
}

public void onKeyPress(KeyPressEvent event) {
if (keyCode == event.getCharCode()) {
// process this keypress as if it were a keydown in other
browsers
}
}

It of course becomes more complex if you also have to deal with keys
that are *expected* to generate keypress (I assume IE/Safari behavior
here).

[1] http://www.w3.org/TR/DOM-Level-3-Events/

Jim Douglas

unread,
Feb 18, 2010, 9:33:10 AM2/18/10
to Google Web Toolkit
Hi Thomas,

Sorry about the delay in responding to this. I just wanted to follow
up on this point:

> Firefox only adds KeyPress events. The issue is Opera here, and *only* Opera.

If that was true, I would tend to agree with you. In my testing,
Opera is almost always the problem child.

But if you have access to a Mac, try that test in Firefox. On the
Mac, Firefox fires *only* keypress for key-repeat of special
characters:

Go to http://unixpapa.com/js/testkey.html and press down-arrow long
enough to trigger a few key-repeats.


Chrome 5.0.322.2:

keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=3
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=3
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=3
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=3
shiftKey=false ctrlKey=false altKey=false metaKey=false
keyup keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=3
shiftKey=false ctrlKey=false altKey=false metaKey=false


Firefox 3.6:

keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=undefined keyLocation=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keyup keyCode=40 (() which=40 (() charCode=0
keyIdentifier=undefined keyLocation=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false


Opera 10.10:

keydown keyCode=40 (() which=40 (() charCode=undefined
keyIdentifier=undefined keyLocation=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false
keypress keyCode=40 (() which=0 charCode=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false
keyup keyCode=40 (() which=40 (() charCode=undefined
keyIdentifier=undefined keyLocation=undefined
shiftKey=false ctrlKey=false altKey=false metaKey=false


Safari 4.0.4:

keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keydown keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=0
shiftKey=false ctrlKey=false altKey=false metaKey=false
keyup keyCode=40 (() which=40 (() charCode=0
keyIdentifier=Down keyLocation=0
shiftKey=false ctrlKey=false altKey=false metaKey=false

> See:http://code.google.com/p/google-web-toolkit/issues/detail?id=3753http://groups.google.fr/group/Google-Web-Toolkit-Contributors/t/e7059...
> andhttp://gwt-code-reviews.appspot.com/142801/show

Reply all
Reply to author
Forward
0 new messages