http://bugs.winehq.org/show_bug.cgi?id=60457 Bug ID: 60457 Summary: The Hankaku/Zenkaku key never reaches the application as WM_KEYDOWN VK_PROCESSKEY with an X input method, so text typed with the IME off is not committed Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs@list.winehq.org Reporter: kagetaro1986@gmail.com Target Milestone: --- Distribution: --- Created attachment 82278 --> http://bugs.winehq.org/attachment.cgi?id=82278 imetest program, logs (Windows 11, Wine unpatched/patched) DESCRIPTION With a Japanese keyboard and an X input method (fcitx5 + mozc), pressing the Hankaku/Zenkaku key (the key that switches the input method on or off) gives the application only a WM_KEYUP of VK_OEM_AUTO. No key down is delivered at all. On Windows 11 the IME processes this key, and the application receives the release followed by WM_KEYDOWN VK_PROCESSKEY. While that message is being handled, ImmGetVirtualKey returns the real key (VK_OEM_AUTO / VK_OEM_ENLW). This is the same in all 8 runs with the current Microsoft IME (ANSI and Unicode windows, 32 and 64 bit, also with -open and -recreate). Some applications keep the text typed with the IME off in their own edit buffer, and commit it when they see this key. A game I use with Wine does this: text typed with the IME off (for example a chat command prefix such as /l ) is committed when the user presses Hankaku/Zenkaku on Windows. On Wine the key never arrives, so that text is replaced by the first Japanese composition. Analysis: the X input method consumes the key press (XFilterEvent), so Wine never generates a key message for it. Only the release reaches ImmProcessKey / ImeProcessKey. This happens with fcitx5's default configuration (fcitx5 handles Hankaku/Zenkaku as its trigger key) and also when mozc handles the key itself. STEPS TO REPRODUCE 1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -o test.log 2. Switch the input method on with Hankaku/Zenkaku, type nihon, press Hankaku/Zenkaku again. Actual: for each Hankaku/Zenkaku press the log only has LOOP WM_KEYUP wp=0x00f3. Expected (Windows 11 logs attached, steps 9 and 10 of the scenario): LOOP WM_KEYUP wp=0x00f3 lp=0xc0290001 LOOP WM_KEYDOWN wp=0x00e5 lp=0x00290001 (VK_PROCESSKEY, ImmGetVirtualKey=0xf3) - log: toggle key releases / VK_PROCESSKEY with ImmGetVirtualKey = VK_OEM_AUTO/ENLW - Windows 11, current Microsoft IME (each of the 8 runs): 2 / 2 - Wine 11.19 unpatched (A-32, W-64): 2 / 0 - Wine 11.19 + patches 0001-0004 (A-32, A-64, W-32, W-64): 2 / 2 PROPOSED PATCH (0004) When ImeProcessKey sees the release of VK_OEM_AUTO, VK_OEM_ENLW or VK_KANJI and nothing is being composed, the builtin IME posts a private notification to the IME UI window. The UI window then sets the virtual key returned by ImmGetVirtualKey (a small helper in imm.c) and posts WM_KEYDOWN VK_PROCESSKEY to the application. The message order is the same as on Windows: release first, then the VK_PROCESSKEY key down. ImeToAsciiEx ignores these keys when the application translates the message, because the host input method has already handled them. With the patch, that game commits the text typed with the IME off when Hankaku/Zenkaku is pressed, as on Windows. Apart from steps 9 and 10, the imetest results are the same as with patches 0001-0003. This is a workaround for a key that the host input method keeps to itself, and advice on a better place for it (for instance winex11 when XFilterEvent consumes a key press) is welcome. The patch applies on top of patch 0003 from bug 60450 (0001 and 0002 are attached to bugs 60447 and 60448). Related: bugs 60448, 60449, 60450. ENVIRONMENT - Ubuntu 24.04.5 LTS, x86_64. Interactive tests on KDE Plasma (X11); the logged runs use Xvfb + openbox. - fcitx5 5.1.7 with fcitx5-mozc 2.28.4715.102 (Japanese), XIM frontend, on-the-spot preedit (UseOnTheSpot=True), LC_ALL=ja_JP.UTF-8, XMODIFIERS=@im=fcitx. - Wine 11.19 built from the WineHQ source (configure --enable-archs=i386,x86_64, i.e. the new WoW64 mode), fresh prefix, no DLL overrides when running the test (Mono/Gecko installation skipped while the prefix was created). Same results with Wine 11.19 + Staging. The files involved (dlls/imm32, dlls/win32u/imm.c, dlls/winex11.drv/xim.c) are unchanged in master as of 2026-10-05. - Comparison: Windows 11 Pro 26H2 (build 26300), Microsoft IME (current version, and the previous version where noted), Japanese 106/109 keyboard. TEST PROGRAM imetest.c (attached, standalone, no dependencies) creates one window with default IME handling and a PeekMessage loop, and logs for every IME and keyboard message whether it was taken from the queue (LOOP) or sent to the window procedure (PROC/sent), and what ImmGetCompositionString, ImmGetOpenStatus and ImmGetConversionStatus return at that moment. IDLE lines record the state once the queue is empty. Build: i686-w64-mingw32-gcc -O1 -o imetest32.exe imetest.c -limm32 -lshell32 -mwindows (64-bit: x86_64-w64-mingw32-gcc). Options: -a ANSI window (default Unicode), -recreate, -open, -auto (types the scenario with SendInput; Windows only), -o <log>. On Wine the scenario was typed through XTEST with drive_x11.py (attached), so that the keys go through the X input method like real key presses. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.