Keypress giving wrong keyCode?

[Rauli]

Hi,

Is this a bug or am I doing something wrong? The problem is that this is giving strange results: http://jsfiddle.net/a2XzH/ (click Run, inspect the console)

For example, if I press Ctrl+Q, I get the keyCode 17, which is Ctrl, not Q. I think the keyCode should be 113, which would be Q. Now I have no way of knowing that Q was pressed (along with Ctrl). I see only the Ctrl.

I tried with Canary, dev and stable versions (35, 36, 37). Firefox seemed to work fine.

What's wrong? This can't be broken or can it? 

Thanks.

[Joshua Bell]

Key events in the Web platform are a bit of a mess [1]

The DOM Level 3 [2] spec defines "keypress" as "If supported by a user agent, this event must be dispatched when a key is pressed down, if and only if that key normally produces a character value."  Since Ctrl+Q doesn't generate a character value, Chrome apparently doesn't send out a code for it. Sending the code for Control is a bit odd, but this might be for compatibility with IE or something. [3]

In general, though, you listen on "keypress" only if you want to track what text the user is inputting (although there are now better events for that, I believe). You listen on "keydown"/"keyup" instead to detect what keys the user is pressing. If you watch "keydown" you'd see an event for the Control key itself, followed by an event for the Q key (with ctrlKey: true)

There is an attempt [4] to bring sanity to this, albeit constrained by backwards compatibility. 

(Pedantic notes: If you're assuming users have a keyboard, you're not designing for the future. If you assume users with a keyboard have a Q key, you're not designing for the world. I'll stop now.)

[1] http://www.quirksmode.org/js/keys.html
[2] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-keypress

[3] IE's key events pretty much matched the Win32 WM_KEYDOWN/WM_KEYUP/WM_CHAR paradigm which was all the rage circa 1996.

[4] https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Rauli]

Thanks for the reply.

I am using keypress, because it fires only once, whereas keydown fires continually (if pressed for too long - which isn't that long actually). I switched to keypress (from keydown) just for that reason.

I think it would be a lot better to assign keyCode the character code and use ctrlKey, altKey etc. to denote the control key pressed. Now keyCode is assigned to 17 (Ctrl) which

- doesn't seem to server any purpose

- makes this event not useful in this particular case.

Also input and beforeinput events don't fire when Ctrl+Q is pressed, so those method also don't work for this.

Now it seems that on Chrome, there isn't a method for this Ctrl+Q case? At least in Firefox it works.

[Joshua Bell]

On Thu, Jul 17, 2014 at 4:48 AM, Rauli <r.ba...@gmail.com> wrote:

Thanks for the reply.

I am using keypress, because it fires only once, whereas keydown fires continually (if pressed for too long - which isn't that long actually). I switched to keypress (from keydown) just for that reason.

The `repeat` property on the event may be helpful then:

http://www.w3.org/TR/DOM-Level-3-Events/#widl-KeyboardEvent-repeat

I think it would be a lot better to assign keyCode the character code and use ctrlKey, altKey etc. to denote the control key pressed. Now keyCode is assigned to 17 (Ctrl) which

- doesn't seem to server any purpose

- makes this event not useful in this particular case.

As mentioned, the existing keyboard event values don't make a huge amount of sense. Changing them induces risk, though, especially as many sites try to hack around the existing weirdness. In general, browser vendors are trying to introduce new, more sensible KeyboardEvent properties to look at (e.g. `key`, `location`, etc) and leaving the old properties alone so that sites don't break.

(This isn't something I work on in Chrome, I've just monkeyed around with it for various hobby projects, so we're reaching the limit of my usefulness here, sorry!)

[Rauli]

The `repeat` property on the event may be helpful then:

That's a good suggestion, but it seems to be always false: http://jsfiddle.net/zJVWb/

I think I have to live with the repeating event then.

As mentioned, the existing keyboard event values don't make a huge amount of sense. Changing them induces risk, though, especially as many sites try to hack around the existing weirdness. In general, browser vendors are trying to introduce new, more sensible KeyboardEvent properties to look at (e.g. `key`, `location`, etc) and leaving the old properties alone so that sites don't break.

I'm just concerned that there might be some bugs here. Maybe I should make a but report at crbug.com and find out.

You've been helpful so far, for sure, so thanks for that.

-R

 

[Joshua Bell]

On Thu, Jul 17, 2014 at 12:46 PM, Rauli <r.ba...@gmail.com> wrote:

The `repeat` property on the event may be helpful then:

That's a good suggestion, but it seems to be always false: http://jsfiddle.net/zJVWb/

I think I have to live with the repeating event then.

Heh, sorry about that. Looks like the impl is incompletely wired up.

I'll make a note in crbug.com/263724

 

As mentioned, the existing keyboard event values don't make a huge amount of sense. Changing them induces risk, though, especially as many sites try to hack around the existing weirdness. In general, browser vendors are trying to introduce new, more sensible KeyboardEvent properties to look at (e.g. `key`, `location`, etc) and leaving the old properties alone so that sites don't break.

I'm just concerned that there might be some bugs here. Maybe I should make a but report at crbug.com and find out.

Yep, that's the right thing to do. 

 

You've been helpful so far, for sure, so thanks for that.

-R

 

--