Closed Bug 680830 Opened 13 years ago Closed 8 years ago

[UI Events] Implement KeyboardEvent.key

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: masayuki, Assigned: masayuki)

References

(Depends on 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file, 7 obsolete files)

testcase
1.22 KB, text/html
Details 
First, we need to reimplement legacy keycode.
We do implement legacy keyCode and charCode.

.char and .key are something new from D3E.
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.
Attached file testcase (obsolete) — 

    
    

    
  
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.

    
    

    
  
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?

    
    

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

    
    

    
  
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.

    
    

    
  
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;

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  

        Attachment #624671 -
        Attachment is obsolete: true

    
    

    
  
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
No longer blocks: 413875

        Attachment #657210 -
        Attachment is obsolete: true

        Attachment #657211 -
        Attachment is obsolete: true

        Attachment #657214 -
        Attachment is obsolete: true

    
    

    
  
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
Blocks: 930893

    
    

    
  
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(?).

    
    

    
  
(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.

    
    

    
  
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
No longer blocks: 479942

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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".

    
    

    
  
(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

    
    

    
  
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.

    
    

    
  
(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 ...

    
    

    
  
(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.
Summary: Implement DOM3 KeyboardEvent.key → [UI Events] Implement KeyboardEvent.key

    
    

    
  
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
Closed: 8 years ago
Resolution: --- → INCOMPLETE

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: