search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
148 stars 51 forks source link

Fire keydown/keyup during composition #75

Open garykac opened 8 years ago

garykac commented 8 years ago

From the thread starting at http://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0024.html

@rniwa:

We've [Apple, Google, Microsoft] been informed that Gecko/Firefox does not fire keydown/keyup events during input method composition for each key stroke. Could someone from Mozilla clarify why this is desirable behavior?

We think it's better to fire keydown/keyup events for consistency across browsers.

@masayuki-nakano:

For the compatibility between other browsers, I agree with changing Gecko's behavior.

However, there is an important thing is, which key value is proper value for keyboard events during composition. For example, in Kana input mode of Japanese IME, ASCII characters vs. Kana characters. Due to the platform limitations, browsers cannot retrieve what character will be inputted into the composition string.

At a meeting of UI Events (or D3E Events), we discussed this issue. IIRC, at that time, we didn't find any proper value but browsers should not dispatch keyboard events during composition (but allowing it for backward compatibility for non-Gecko browsers, therefore, currently defined with MAY).

I believe that web authors shouldn't handle keyboard events for text input. I.e., shouldn't need keyboard events during composition because such applications cannot support handwriting system and/or speech input system. At least spec should recommend web authors should handle "compositionupdate", "beforeinput" and/or "input". Handling keydown/keyup event during composition means that a keydown/keyup event causes double action (default action, i.e., modifying composition string and web app specific action).

Mozilla's tracking bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=354358

garykac commented 8 years ago

I removed the text relating to allowing keydown and keyup to be suppressed during composition. Leaving this bug open until I add some text describing how key values should be assigned in these events during composition.

masayuki-nakano commented 7 years ago

Oh, currently, Chrome uses "Process" for VK_PROCESS on Windows. The native virtual key code value means that the key event has already been handled (consumed) by IME. However, Chromium on Linux doesn't behave so. It fires ASCII character which is inputted when IME is closed even if I use Kana input mode.

Edge fires keydown event with key value "Unidentified" but fires keyup event with key value with ASCII character which is inputted when IME is closed.

I'm now planning to work on making Firefox dispatch keydown/keyup event even in composition. However, this key value inconsistency is now a big problem, which should refer or using better key value.

@garykac what do you think?