Last Comment Bug 680830 - [UI Events] Implement KeyboardEvent.key
: [UI Events] Implement KeyboardEvent.key
Status: RESOLVED INCOMPLETE
: meta
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 19 votes (vote)
: ---
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on: 773526 865564 1232915 631165 751749 757688 762758 764285 768287 769159 769190 769548 773651 775414 842927 865561 865565 865566 900372 912858 930900 1121878
Blocks: 680829 930893
  Show dependency treegraph
 
Reported: 2011-08-21 22:11 PDT by Masayuki Nakano [:masayuki] (Mozilla Japan)
Modified: 2016-11-10 02:59 PST (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (751 bytes, text/html)
2012-05-17 00:44 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
testcase (1.22 KB, text/html)
2012-06-04 23:36 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
part.1 Add KeyboardEvent.char and KeyboardEvent.key (23.77 KB, patch)
2012-07-19 00:28 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows (26.21 KB, patch)
2012-07-19 00:28 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa (12.87 KB, patch)
2012-07-19 00:29 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
part.1 Add KeyboardEvent.char and KeyboardEvent.key (23.48 KB, patch)
2012-08-31 03:50 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows (25.30 KB, patch)
2012-08-31 03:51 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa (11.44 KB, patch)
2012-08-31 03:52 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review

Description Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-08-21 22:11:50 PDT
First, we need to reimplement legacy keycode.
Comment 1 Olli Pettay [:smaug] 2011-08-22 01:45:47 PDT
We do implement legacy keyCode and charCode.

.char and .key are something new from D3E.
Comment 2 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 00:21:37 PDT
I landed the patches reimplementing legacy keycodes. I'm going to make patches for this bug soon. I hope that this will be fixed on 16.
Comment 3 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 00:44:26 PDT
Created attachment 624671 [details]
testcase
Comment 4 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 01:02:47 PDT
Something strange:

* IE9 uses "Scroll" for ScrollLock key. D3E spec said that it should be "ScrollLock". But comparing with getModifierState(), it should be "Scroll". I think the spec should be modified.

* IE9 uses "Win" for Windows logo key. D3E spec said that it should be "OS". Comparing with getModifierState(), it should be "Win" but I'm not sure if a proper noun should be used in W3C's spec.

* IE9 users "Attn" for Alt+Katakana-Hiragana, I think that it should be "JapaneseRomaji".

* IE9 users some key names for Japanese IME on Japanese Windows7 even when I'm using Korean IME.
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 01:19:23 PDT
Hmm, I was thinking that internal key value should be stored by atom pointer. However, it cannot be cross process boundary in nsGUIEventIPC.h. So, I'll use nsString for key. Does somebody have better idea?
Comment 6 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 01:37:31 PDT
Ah, the key names can be indicated by int values (only for trusted event).
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 02:52:09 PDT
Ugh... I got this error:

error: name 'char' is a builtin and cannot be redeclared, m:/mc-q/src/dom/interfaces/events/nsIDOMKeyEvent.idl line 245:11
  readonly attribute DOMString char;

How do I define char property?
Comment 8 Olli Pettay [:smaug] 2012-05-17 02:55:28 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #5)
> Hmm, I was thinking that internal key value should be stored by atom
> pointer. However, it cannot be cross process boundary in nsGUIEventIPC.h.
> So, I'll use nsString for key. Does somebody have better idea?
Well, you can always serialize atom to string and then back to atom.
Comment 9 Olli Pettay [:smaug] 2012-05-17 03:01:15 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #7)
> Ugh... I got this error:
> 
> error: name 'char' is a builtin and cannot be redeclared,
> m:/mc-q/src/dom/interfaces/events/nsIDOMKeyEvent.idl line 245:11
>   readonly attribute DOMString char;
> 
> How do I define char property?

Uh, that is painful. Do we need something new in xpidl.py, something similar to 'binaryname'?
Kyle might know.
Comment 10 Olli Pettay [:smaug] 2012-05-17 03:04:46 PDT
Or do we support the _  (underscore-prefix) hack webidl has.
Comment 11 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-05-17 05:45:19 PDT
_ works, iirc.
Comment 12 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 17:53:09 PDT
Hmm, _char still failed...


> nsIDOMKeyEvent.idl
> error: unrecognized input, m:/mc-q/src/dom/interfaces/events/nsIDOMKeyEvent.idl line 245:31
>   readonly attribute DOMString _char;
>                                ^
> Traceback (most recent call last):
>   File "m:\mc-q\src\build\pymake\pymake\process.py", line 213, in run
>     m.__dict__[self.method](self.argv)
>   File "m:/mc-q/src/config\pythonpath.py", line 44, in main
>     execfile(script, frozenglobals)
>   File "m:/mc-q/firefox-debug-build/dist/sdk/bin/header.py", line 529, in <module>
>     idl = p.parse(open(file).read(), filename=file)
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\xpidl.py", line 1596, in parse
>     idl = self.parser.parse(lexer=self)
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\ply\yacc.py", line 265, in parse
>     return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\ply\yacc.py", line 921, in parseopt_notrack
>     lookahead = get_token()     # Get the next token
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\xpidl.py", line 1585, in token
>     t = self.lexer.token()
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\ply\lex.py", line 384, in token
>     newtok = self.lexerrorf(tok)
>   File "m:\mc-q\firefox-debug-build\dist\sdk\bin\xpidl.py", line 1195, in t_ANY_error
>     lexpos=self.lexer.lexpos))
> IDLError: error: unrecognized input, m:/mc-q/src/dom/interfaces/events/nsIDOMKeyEvent.idl line 245:31
>   readonly attribute DOMString _char;
Comment 13 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 18:46:48 PDT
I realized that after this bug is fixed, keydown event has charValue which will be dispatched by keypress event(s). So, I think that ESM will be able to keypress event(s) from PostHandleEvent() of keydown event. It should make the widget code simpler.
Comment 14 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-05-17 19:41:28 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #13)
> I realized that after this bug is fixed, keydown event has charValue which
> will be dispatched by keypress event(s). So, I think that ESM will be able
> to keypress event(s) from PostHandleEvent() of keydown event. It should make
> the widget code simpler.

Ah, this could be so if we continue our current behavior. However, D3E spec wants preventDefault() of keydown event to be able to prevent composition. So, in the future, we need to dispatch keydown event before composition and only when composition isn't started, keypress event(s) is needed.
Comment 15 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-06-04 23:35:38 PDT
I documented the IE9's behavior:

https://developer.mozilla.org/en/DOM/KeyboardEvent#Key_names_and_Char_values
Comment 16 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-06-04 23:36:57 PDT
Created attachment 630086 [details]
testcase
Comment 17 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-07-19 00:28:02 PDT
Created attachment 643752 [details] [diff] [review]
part.1 Add KeyboardEvent.char and KeyboardEvent.key
Comment 18 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-07-19 00:28:34 PDT
Created attachment 643753 [details] [diff] [review]
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows
Comment 19 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-07-19 00:29:02 PDT
Created attachment 643754 [details] [diff] [review]
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa
Comment 20 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-07-19 22:44:38 PDT
I'm thinking the char value and the key value when Ctrl or Alt is pressed, especially on non Latin alphabet inputtable keyboard layout like Arabic or Cyrillic. I filed a bug for the spec and suggested my idea:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341
Comment 21 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-31 03:50:57 PDT
Created attachment 657210 [details] [diff] [review]
part.1 Add KeyboardEvent.char and KeyboardEvent.key
Comment 22 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-31 03:51:28 PDT
Created attachment 657211 [details] [diff] [review]
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows
Comment 23 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-31 03:52:09 PDT
Created attachment 657214 [details] [diff] [review]
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa
Comment 24 Masayuki Nakano [:masayuki] (Mozilla Japan) 2013-09-04 23:37:01 PDT
KeyboardEvent.char is now dropped from D3E draft.
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-keyboardevents
Comment 25 Jukka Jylänki 2014-01-21 08:27:58 PST
I noticed something odd while testing this page today: https://dl.dropboxusercontent.com/u/40949268/Bugs/key_events_garbage.html

Pressing tab in Firefox Stable 26 and Nightly 29, the text "earFavo" gets printed to console. Pressing Enter prints out the text "AltGraphC". Pressing esc prints "idateC", F1 gives "F16F", F2 gives "7F18", etc, and other keys give out odd strings as well, like "rackS", "ediaPrevi", "kSkipMedia", etc. I know https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent?redirectlocale=en-US&redirectslug=DOM%2FKeyboardEvent says event.key is not implemented yet, but getting random strings there sounds like another bug(?).
Comment 26 Masayuki Nakano [:masayuki] (Mozilla Japan) 2014-01-21 08:36:53 PST
(In reply to Jukka Jylänki from comment #25)
> I noticed something odd while testing this page today:
> https://dl.dropboxusercontent.com/u/40949268/Bugs/key_events_garbage.html
> 
> Pressing tab in Firefox Stable 26 and Nightly 29, the text "earFavo" gets
> printed to console. Pressing Enter prints out the text "AltGraphC". Pressing
> esc prints "idateC", F1 gives "F16F", F2 gives "7F18", etc, and other keys
> give out odd strings as well, like "rackS", "ediaPrevi", "kSkipMedia", etc.
> I know
> https://developer.mozilla.org/en-US/docs/Web/API/
> KeyboardEvent?redirectlocale=en-US&redirectslug=DOM%2FKeyboardEvent says
> event.key is not implemented yet, but getting random strings there sounds
> like another bug(?).

Hmm, perhaps, it's a regression of bug 957659...
Comment 27 Nathan Froyd [:froydnj] 2014-01-21 08:39:59 PST
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #26)
> (In reply to Jukka Jylänki from comment #25)
> > I noticed something odd while testing this page today:
> > https://dl.dropboxusercontent.com/u/40949268/Bugs/key_events_garbage.html
> > 
> > Pressing tab in Firefox Stable 26 and Nightly 29, the text "earFavo" gets
> > printed to console. Pressing Enter prints out the text "AltGraphC". Pressing
> > esc prints "idateC", F1 gives "F16F", F2 gives "7F18", etc, and other keys
> > give out odd strings as well, like "rackS", "ediaPrevi", "kSkipMedia", etc.
> > I know
> > https://developer.mozilla.org/en-US/docs/Web/API/
> > KeyboardEvent?redirectlocale=en-US&redirectslug=DOM%2FKeyboardEvent says
> > event.key is not implemented yet, but getting random strings there sounds
> > like another bug(?).
> 
> Hmm, perhaps, it's a regression of bug 957659...

Yes, I think so; the offsets for the table are incorrect.
Comment 28 Masayuki Nakano [:masayuki] (Mozilla Japan) 2014-05-08 01:27:26 PDT
The documentation is now an independent document due to a lot of big tables make KeyboardEvent document messy.
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key
Comment 29 Florian Bösch 2014-05-21 00:48:58 PDT
Note that specification on MDN and W3C miss the ability to translate a code or key value to the cap on a users keyboard.

This has been discussed on the wepapps-ml and I don't know why it's now absent. However this is an important part to make keyboard layouts/shortcuts work.

The same physical key (by code or key) on a keyboard in different locales, can be labelled differently depending on the keyboard locale. For instance, the popular WASD control scheme for first person shooters, would look like "صشسي" (yes that's 4 keys) on an arabic keyboard in the primary printing on the keys.

If you're going to offer a default key/shortcut configuration (for instance for a first person shooter game) and/or make the keys configurable, you'd like to present the user with a dialog that shows the configured keys according to the primary, unmodified letter printed on the key cap.

For this reason a getKeyCap(code) -> unicode char method has been discussed, which is presently absent.
Comment 30 Masayuki Nakano [:masayuki] (Mozilla Japan) 2014-05-21 02:54:36 PDT
Florian:

It's really out of scope of this bug. And the issue you mentioned is very complicated to define and implement. Therefore, D3E people decided that it doesn't include D3E. It should be solved in future spec. Anyway, our current goal is, KeyboardEvent represents more information and makes better compatibility between browsers, platforms and physical/virtual keyboard.

FYI:

KeyboardEvent.key represents the key behavior depending on keyboard layout and modifier state.
KeyboardEvent.code represents physical key identifier, emulates physical key if it's synthesized by VKB.
Comment 31 meklu 2014-10-21 06:12:39 PDT
Something of note: apparently the currently returned values for the Escape key in FF (32.0.2 at least) differ from the values in W3C's drafts:

  http://www.w3.org/TR/DOM-Level-3-Events-code/#key-function-section
  http://www.w3.org/TR/DOM-Level-3-Events-key/#keys-ui

Firefox gives "Esc" for both KeyboardEvent.key and KeyboardEvent.code, whereas the draft says they should be "Escape".
Comment 32 meklu 2014-10-21 06:21:27 PDT
(In reply to meklu from comment #31)
> Something of note: apparently the currently returned values for the Escape
> key in FF (32.0.2 at least) differ from the values in W3C's drafts:
> 
>   http://www.w3.org/TR/DOM-Level-3-Events-code/#key-function-section
>   http://www.w3.org/TR/DOM-Level-3-Events-key/#keys-ui
> 
> Firefox gives "Esc" for both KeyboardEvent.key and KeyboardEvent.code,
> whereas the draft says they should be "Escape".

Pardon the rapid successive post. This might also just be an issue with the X11/Linux backend, as even MDN says it should be "Escape".

  https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key
Comment 33 Masayuki Nakano [:masayuki] (Mozilla Japan) 2014-10-21 09:15:50 PDT
See bug 900372. And the reason why we've not fixed them yet is, we are waiting some issues which will be fixed in the draft.
Comment 34 Samuel Bronson 2014-11-22 09:47:12 PST
(In reply to Florian Bösch from comment #29)
> The same physical key (by code or key) on a keyboard in different locales,
> can be labelled differently depending on the keyboard locale. For instance,
> the popular WASD control scheme for first person shooters, would look like
> "صشسي" (yes that's 4 keys) on an arabic keyboard in the primary printing on
> the keys.
> 
> If you're going to offer a default key/shortcut configuration (for instance
> for a first person shooter game) and/or make the keys configurable, you'd
> like to present the user with a dialog that shows the configured keys
> according to the primary, unmodified letter printed on the key cap.

I can't help but wonder: how is the browser (or any other software) supposed to know what (if anything) is printed on the keys?  I suppose it could ask the user to supply a photo of the keyboard, then detect things that look like keys and ask them to press each one in turn ...
Comment 35 Florian Bösch 2015-01-15 01:40:32 PST
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #30)
> Florian:
> 
> It's really out of scope of this bug. And the issue you mentioned is very
> complicated to define and implement. Therefore, D3E people decided that it
> doesn't include D3E. It should be solved in future spec. Anyway, our current
> goal is, KeyboardEvent represents more information and makes better
> compatibility between browsers, platforms and physical/virtual keyboard.

Yes the issue is complicated to implement (it's not that difficult to define). The definition is actually quite simple. Whenever you need to present the user with any kind of display of configured keys (whereever it comes from), it should be possible to show the user something which does not utterly confuse him because the keys displayed, don't actually exist on his keyboard as printed on the key-caps.

Properly localized/internationalized native application, including browsers themselves, perform this function using the operating systems locale and keyboard layout databases.

Unless functionality like this is included, it will be impossible to provide good configuration dialogs for keyboard shortcuts that web applications use. Excluding translation of key-caps, does enable web applications to handle shortcuts reliably, it does not allow them to communicate those shortcuts to the user reliably.
Comment 36 Masayuki Nakano [:masayuki] (Mozilla Japan) 2016-07-05 18:33:29 PDT
Please search with [UIEvents] and [UIEvents-key] for new bugs. I close this meta bug because we've already not used for new bugs and you can search new bugs easy.

Note You need to log in before you can comment on or make changes to this bug.