[Bug 60457] New: 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

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
  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.

[Bug 60457] 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

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60457

--- Comment #1 from Kagetaro078 <[e-mail]> ---
Created attachment 82279
  --> http://bugs.winehq.org/attachment.cgi?id=82279
Proposed patch

-- 
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.

[Bug 60457] 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

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60457

--- Comment #2 from Kagetaro078 <[e-mail]> ---
Still the same with Wine 11.19 and current master (dlls/imm32,
dlls/win32u/imm.c and
dlls/winex11.drv/xim.c are unchanged). I have since moved to Ubuntu 26.04.1
(KDE Plasma 6, Wayland session, Wine on XWayland, fcitx5 XIM frontend);
the behaviour is identical there and the attached patch still applies and
fixes it. The attached logs were made in Xvfb and are not affected by the
desktop change.

-- 
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.