search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 52 forks source link

preventDefault() of keydown event should not kill composition start caused by the keydown #180

Open masayuki-nakano opened 6 years ago

masayuki-nakano commented 6 years ago

Current spec said: https://w3c.github.io/uievents/#event-type-keydown

The default action of the keydown event depends upon the key:

  • ...
  • If the key is associated with a text composition system, the default action MUST be to launch that system

And also:

If this event is canceled, the associated event types MUST NOT be dispatched, and the associated actions MUST NOT be performed.

However, as far as I've tested current released versions of desktop browsers, no browser stops sending keydown event to IME (or cancels composition immediately after compositionstart).

So, if web browsers change current behavior, that causes breaking backward compatibility and nobody becomes happy with currently speced behavior.

Therefore, those declaration should be changed or just add exception for compositionstart.

masayuki-nakano commented 6 years ago

FYI: I tested it with Firefox on Windows 10, macOS and Linux, Chrome on Windows 10 and macOS, Chromium on Linux, Edge on Windows 10, Safari on macOS.

tszynalski commented 4 years ago

I disagree. The spec is fine.

If a web application calls KeyboardEvent.preventDefault(), that means it is using the given key for its own purposes (as a hotkey).

For example, let's take the key to the right of P, which starts a composition on MacOS with the French keyboard layout. I may want to use that key in my Web app for some feature. In that case, I want to be able to call .preventDefault() to suppress the native functionality (just like I can suppress the native functionality of F, G or C). It doesn't make sense to make an exception for compositions.

masayuki-nakano commented 4 years ago

Please note that, native IME may handle native key down event before browser receives it. When you see keyCode === 0xE5 of keydown event before compositionstart, it means that the keydown event has already been handled by IME (at least on Windows). That's the reason why current spec does not make sense technically.

tszynalski commented 4 years ago

@masayuki-nakano I understand it may be hard, but isn't it possible to prevent Windows from opening the IME, for example by installing a low-level keyboard hook?

masayuki-nakano commented 4 years ago

Could be. However, there was a similar issue on Linux's GTK applications a decade or more ago (I don't know current status though). That is, the priority of IME key handling on GTK widget was lower than hot keys specified by application. That caused some IME users couldn't use IME on some applications. Then, IME started to use global key hook for wining GTK. So, I think that if web apps can do something for some key combinations which IME wants to use may reproduce such a11y issue on the web or IME starts to to hack something when browser has focus...

tszynalski commented 4 years ago

There can be good reasons for blocking IMEs in a Web app. For example, in a browser game, you don't care about IME input. So I don't think there should be a hard "no IME blocking" rule. If a Web app is blocking your IME without good reason, I think the solution is to (1) complain to the author, or (2) do not use the Web app. I would not expect this to be a widespread problem on the Web.