The default bug view has changed. See this FAQ.

[UI Events] Implement KeyboardEvent.key

RESOLVED INCOMPLETE

Status

()

Core
DOM: Events
RESOLVED INCOMPLETE
6 years ago
5 months ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(Depends on: 3 bugs, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 7 obsolete attachments)

(Assignee)

Description

6 years ago
First, we need to reimplement legacy keycode.
We do implement legacy keyCode and charCode.

.char and .key are something new from D3E.
(Assignee)

Comment 2

5 years ago
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.
(Assignee)

Comment 3

5 years ago
Created attachment 624671 [details]
testcase
(Assignee)

Comment 4

5 years ago
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.
(Assignee)

Comment 5

5 years ago
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?
(Assignee)

Comment 6

5 years ago
Ah, the key names can be indicated by int values (only for trusted event).
(Assignee)

Comment 7

5 years ago
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?
(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.
(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.
Or do we support the _  (underscore-prefix) hack webidl has.
_ works, iirc.
(Assignee)

Comment 12

5 years ago
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;
(Assignee)

Comment 13

5 years ago
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.
(Assignee)

Comment 14

5 years ago
(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.
Keywords: dev-doc-needed
(Assignee)

Updated

5 years ago
Depends on: 757688
(Assignee)

Updated

5 years ago
Blocks: 479942
(Assignee)

Comment 15

5 years ago
I documented the IE9's behavior:

https://developer.mozilla.org/en/DOM/KeyboardEvent#Key_names_and_Char_values
(Assignee)

Comment 16

5 years ago
Created attachment 630086 [details]
testcase
Attachment #624671 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Depends on: 762758
(Assignee)

Updated

5 years ago
Depends on: 764285
(Assignee)

Updated

5 years ago
Depends on: 751749, 769159, 768287
(Assignee)

Updated

5 years ago
Depends on: 769190
(Assignee)

Updated

5 years ago
Depends on: 769548
(Assignee)

Updated

5 years ago
Depends on: 773651
(Assignee)

Updated

5 years ago
Depends on: 775414
(Assignee)

Comment 17

5 years ago
Created attachment 643752 [details] [diff] [review]
part.1 Add KeyboardEvent.char and KeyboardEvent.key
(Assignee)

Comment 18

5 years ago
Created attachment 643753 [details] [diff] [review]
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows
(Assignee)

Comment 19

5 years ago
Created attachment 643754 [details] [diff] [review]
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa
(Assignee)

Comment 20

5 years ago
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
(Assignee)

Comment 21

5 years ago
Created attachment 657210 [details] [diff] [review]
part.1 Add KeyboardEvent.char and KeyboardEvent.key
Attachment #643752 - Attachment is obsolete: true
(Assignee)

Comment 22

5 years ago
Created attachment 657211 [details] [diff] [review]
part.2 Implement KeyboardEvent.char and KeyboardEvent.key on Windows
Attachment #643753 - Attachment is obsolete: true
(Assignee)

Comment 23

5 years ago
Created attachment 657214 [details] [diff] [review]
part.3 Implement KeyboardEvent.char and KeyboardEvent.key on Cocoa
Attachment #643754 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Blocks: 413875
(Assignee)

Updated

4 years ago
No longer blocks: 413875
(Assignee)

Updated

4 years ago
Depends on: 842927
(Assignee)

Updated

4 years ago
Depends on: 865561
(Assignee)

Updated

4 years ago
Depends on: 865564
(Assignee)

Updated

4 years ago
Depends on: 865565
(Assignee)

Updated

4 years ago
Depends on: 865566
(Assignee)

Updated

4 years ago
Attachment #657210 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #657211 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #657214 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Depends on: 773526
(Assignee)

Updated

4 years ago
Depends on: 900372
(Assignee)

Comment 24

4 years ago
KeyboardEvent.char is now dropped from D3E draft.
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-keyboardevents
Keywords: meta
Summary: Implement DOM3 KeyboardEvent.char and KeyboardEvent.key → Implement DOM3 KeyboardEvent.key
(Assignee)

Updated

4 years ago
Depends on: 912858
(Assignee)

Updated

4 years ago
Depends on: 930900
Blocks: 930893

Comment 25

3 years ago
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(?).
(Assignee)

Comment 26

3 years ago
(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...
(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.
(Assignee)

Comment 28

3 years ago
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
(Assignee)

Updated

3 years ago
No longer blocks: 479942

Comment 29

3 years ago
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.
(Assignee)

Comment 30

3 years ago
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

3 years ago
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

3 years ago
(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
(Assignee)

Comment 33

3 years ago
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

2 years ago
(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 ...
(Assignee)

Updated

2 years ago
Depends on: 1121878

Comment 35

2 years ago
(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.
(Assignee)

Updated

a year ago
Depends on: 1232915
(Assignee)

Updated

a year ago
Summary: Implement DOM3 KeyboardEvent.key → [UI Events] Implement KeyboardEvent.key
(Assignee)

Comment 36

9 months ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → INCOMPLETE
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.