Fix microsoft ime input #1058
Fix microsoft ime input #1058
Conversation
IDisposable
left a comment
IDisposable
left a comment
There was a problem hiding this comment.
Not sure, but I think we should not be ignoring the keydown event unless the client is a windows machine (like we test when synthesizing the down/up)
| // Microsoft IME fix: | ||
| // Effective keydown events are consumed by IME (reported as "Process"), | ||
| // so we handle the full press/release cycle in the keyup handler instead. | ||
| if (["Zenkaku", "Hankaku", "ZenkakuHankaku"].includes(e.key)) { |
There was a problem hiding this comment.
Do we want to ignore them here only on isWindowClient condition?
There was a problem hiding this comment.
The IME keydown bypass is currently placed inside the isWindowsClient condition, so this logic runs only on Windows.
Since Windows is the only platform I can reliably test at the moment, I would prefer to keep this PR Windows-only for now.
However, I also have access to Linux and macOS, so I can follow up with a separate PR to address non-Windows IME behavior as well.
For reference, here is what I have observed so far:
- On Linux (Ubuntu 25.10 + Mozc Japanese input method), pressing the Hankaku/Zenkaku key emits only a keyup event.
- On macOS, the Hankaku/Zenkaku key is not used. Instead, 英数 (key: Eisu, code: Lang2) and かな (key: KanjiMode, code: Lang1) are used — and both produce only keyup events as well.
Figure 1. Linux(ubuntu + mozc) Keyboard Event
Figure 2. macOS Keyboard Event
Figure 3. Mac Keyboard(JIS) 英数 and かな keys
I will verify these behaviors more thoroughly and submit an additional PR to handle Linux and macOS explicitly.
2 participants
fix #740