Open masayuki-nakano opened 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.
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.
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.
@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?
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...
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.
Current spec said: https://w3c.github.io/uievents/#event-type-keydown
And also:
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.