New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 644140 link

Starred by 2 users
Status: Archived
Owner:
dtapu...@chromium.org
Closed: Sep 18
Cc:
fukino@chromium.org
sadrul@chromium.org
w...@chromium.org
kpschoedel@chromium.org
dtapu...@chromium.org
█ chongz@chromium.org
garykac@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

KeyEvent.key should not reconstruct the original key code when VKEY_PROCESSKEY arrives.

Project Member Reported by nona@chromium.org, Sep 6 2016 
Version: M54 (at least M52 has the same behavior)
OS: Chroem OS/Mac OSX

What steps will reproduce the problem?
(1) Open http://nonan.jp/keyevent/input
(2) Focus to the input box and enable Japanese IME
(3) Hit "a" and "Enter"

The event log is as follows:

keydown e.key="a" e.keyCode=229
keyup e.key="a" e.keyCode=65
keydown e.key="Enter" e.keyCode=229
keyup e.key="Enter" e.keyCode = 13

The keycode 229 is VKEY_PROCESSKEY which mean the keyboard event was consumed by IME so the application should not process it.

I think e.key should also have the same value of e.keyCode for the backward compatibility after deprecation of e.keyCode.

Looks like there is a documentation for VKEY_PROCESSKEY(229) for keyCode in UI Event W3C specification but looks no for KeyboardEvent.key.
https://www.w3.org/TR/uievents/

We may need help from W3C DOM UI Event expert.
consumed_keyevent_bad.png
209 KB View Download

Comment 1 by nona@chromium.org, Sep 6 2016

Labels: -Pri-3 Pri-2
Owner: sadrul@chromium.org
Status: Assigned (was: Untriaged)
Sadrul, could you help to find the expert of the Chrome and DOM keyboard event?

Thank you.

Comment 2 by nona@chromium.org, Sep 6 2016

Cc: shuchen@chromium.org fukino@chromium.org

Comment 3 by sadrul@chromium.org, Sep 6 2016

Cc: sadrul@chromium.org w...@chromium.org kpschoedel@chromium.org
Components: UI>Input>Text>IME
Owner: dtapu...@chromium.org
--> dtapuska@, /cc+ wez@, kpschoedel@

Comment 4 by nona@chromium.org, Sep 6 2016 

I find a good reference for this.
KeyboardEvent.key has "Process" for VKEY_PROCESSKEY, so probably we may need to do similar things to other platforms.
IMG_20160906_131213.jpg
2.2 MB View Download

Comment 5 by nona@chromium.org, Sep 6 2016 

I forgot mentioning about the platform. The photo was taken on Windows 7 with Chrome M 52.

Thanks.

Comment 6 by dtapu...@chromium.org, Sep 6 2016

Cc: -shuchen@chromium.org dtapu...@chromium.org
Owner: chongz@chromium.org
chongz@ please take a look.

Comment 7 by chongz@chromium.org, Sep 6 2016

Cc: garykac@chromium.org
CCing garykac@ for spec confirmation.

UI Events spec has examples about IME and dead keys, and from my understanding the DomKey value should be the value of the key (which is what Chrome is doing right now).

Examples:
  1. Japanese IME: https://w3c.github.io/uievents/#example-91064bc0
    * Check event 1) 's' keydown and 7) 'i' keydown, the KeyboardEvent.key is "s" & "i", and the composition is on-going.

  2. Dead keys: https://w3c.github.io/uievents/#example-d2fc8767
    * Dead keys could also start composition, and the DomKey value is "Dead" and "ê".

Comment 8 by dtapu...@chromium.org, Sep 27 2016

Labels: Hotlist-Input-Dev

Comment 9 by chongz@chromium.org, Jan 10 2017

Cc: chongz@chromium.org
Owner: dtapu...@chromium.org
garykac@ Can you comment on this issue for spec clarification? Thanks!

Also re-assigning to dtapuska@ as I'm switching.

Comment 10 by markchang@chromium.org, Sep 18

Status: Archived (was: Assigned)
Archiving old bugs that have only received trivial updates for some time.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
►

Sign in to add a comment