New subject: [Bug 60450] ImmGetOpenStatus does not follow the X input method: IME reported closed while text is committed, and open while the input method is off

Oct. 6, 2026

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

            Bug ID: 60450
           Summary: ImmGetOpenStatus does not follow the X input method:
                    IME reported closed while text is committed, and open
                    while the input method is off
           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 82266
  --> http://bugs.winehq.org/attachment.cgi?id=82266
imetest test program, comparison and logs (normal and -open runs; Windows 11,
Wine unpatched/patched) with terminal output

DESCRIPTION

The X input method (fcitx5 + mozc) does not report when the user switches it on
or off, and cannot be
switched on by the application (fcitx5 ignores XNPreeditState). Wine's builtin
IME therefore guesses
the open status: open when a composition starts, closed when it ends. Compared
with Windows 11:

- Around a commit, Windows keeps the IME open; Wine closes it right after each
commit
  (IMN_SETOPENSTATUS), a few milliseconds before the application receives the
committed characters.
- A full-width space typed with nothing composed is committed while Wine
reports the IME closed;
  on Windows the IME is open.
- When the application opens the IME with ImmSetOpenStatus(TRUE), Windows
switches the IME on (typing
  produces a composition). On Wine the IME is reported open while the input
method is still off;
  typed characters arrive as plain WM_CHAR with ImmGetOpenStatus() == 1, and
applications that wait
  for IME input while the IME is open ignore them.

STEPS TO REPRODUCE

1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -o test.log;
switch the input method
   on, press Space with nothing composed: the commit of U+3000 is logged with
open=0.
2. wine imetest32.exe -a -open -o open.log (the program calls
ImmSetOpenStatus(TRUE) after creating
   its window); with the input method off, type abc: the WM_CHAR lines show
open=1.

Expected (Windows 11 logs attached): open=1 during commits; with -open, abc
becomes a composition.

PROPOSED WORKAROUND (PATCH 0003, RFC)

This is heuristic, and advice on a better approach is welcome (for instance a
way to query or set the
state of the input method):
- close the IME 300 ms after a composition ends instead of immediately, unless
a new composition starts;
- open the IME for a commit that arrives without a composition, and close it
again after the delay;
- when a character key (letters, digits, OEM, numpad; no Ctrl/Alt) reaches
ImeProcessKey while the IME
  is open and nothing is composed, the input method did not use it, so it is
off: close the IME before
  the key is delivered.

With the patch, commits happen with open=1, and with -open the first typed
character arrives with
open=0 (on Windows the IME would really be on; this cannot be done through
XIM).
The patch applies on top of patch 0002 from bug 60448. Possibly related: bug
54988.

Not a Wine issue, for reference: when fcitx5's trigger key (Zenkaku_Hankaku)
switches the input method
off during a composition, fcitx5 clears the preedit without committing it (no
commit over XIM), so the
composition is lost, with or without the patch. Windows 11's current Microsoft
IME keeps the
composition and switches to alphanumeric mode.

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 60450] New: ImmGetOpenStatus does not follow the X input method: IME reported closed while text is committed, and open while the input method is off

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)