Adding a Linux / X11 data point. It's the same "text input machinery engaged outside text fields" mechanism, taken one step further: here the IME cannot compose at all (plain ASCII engine), and gameplay keys are silently swallowed anyway.
GNOME on Xorg ({{XDG_SESSION_TYPE=x11}}), ibus session IM ({{ibus-daemon --panel disable --xim}}) with a plain ASCII engine active. No Chinese engine, no CJK content, and no candidate window ever appears. The faulty state does not require a compositional IME.
Instance is modded. I removed the input-relevant mods (Controlify, Debugify, Ixeris) one at a time; the issue persisted after each removal.
h3. Measurements, layer by layer
evdev: With W + Left Ctrl held (Ctrl pressed before, released after), I pressed Space × 6 during normal gameplay. The keyboard HID device ({{/dev/input/event4}}) shows all 6 down+up pairs delivered normally ({{MSC_SCAN}} raw={{0x7002c}}). The game registered 0 of 6, so the jump key vanishes (symptom: can't sprint-jump).
Combo tests:
** W + L-Ctrl + Space → 0/1 ** W + R-Ctrl + Space → 0/1 (R-Ctrl is bound to nothing, which rules out sprint logic and isolates the Control modifier itself) ** W + L-Shift + Space → 1/1 (other modifiers don't trigger the swallow)
Conclusion: Keys reach the kernel intact. The loss happens inside the game's input path whenever {{ControlMask}} is active, consistent with this issue's mechanism: the SDL/IME layer is armed during gameplay even though no text field exists.
h3. GLFW-era workaround is inert on this stack {{XMODIFIERS=@im=null}} (the old MC-122421 escape hatch) has no effect. I verified both {{@im=none}} and {{@im=null}} with full restarts, still 0/6. This matches SDL3's X11 IME integration using ibus over the DBus session bus rather than XIM.
h3. Note on the OpenGL root-cause analysis above The snapshot-9 temporary-window analysis is Windows-specific (cached HWND). What the Windows data can't show: on X11 the mis-targeting happens regardless of IME state. Mine never visibly toggles (an ASCII engine can't compose), yet the swallow still occurs, so text-input arming is independent of whether an IME language is active.
I couldn't verify Vulkan here (the pack crashes on the Linux Vulkan path, unrelated), so whether Vulkan also avoids this on X11 is still open for someone else to test.
h3. Request Could you fold the Linux/X11 + ibus path into this ticket's scope? A Windows-specific window-creation-order fix likely wouldn't touch X11, where the same state shows up as silent key loss rather than a toggling indicator. Enforcing {{SDL_StopTextInput}} whenever gameplay resumes from any non-text screen would cover ibus users with default ASCII setups as well.
i just tested it in 26.1.2. still happens. while the id of a water bottle is minecraft:potion it is pretty clear that this should be changed just by the spirit of the advancement
Adding a Linux / X11 data point. It's the same "text input machinery engaged outside text fields" mechanism, taken one step further: here the IME cannot compose at all (plain ASCII engine), and gameplay keys are silently swallowed anyway.
h3. Environment
Minecraft Java 26.3 release (Fabric, Fabulously Optimized alpha), windowed, OpenGL, Mesa/RADV (AMD)
GNOME on Xorg ({{XDG_SESSION_TYPE=x11}}), ibus session IM ({{ibus-daemon --panel disable --xim}}) with a plain ASCII engine active. No Chinese engine, no CJK content, and no candidate window ever appears. The faulty state does not require a compositional IME.
Instance is modded. I removed the input-relevant mods (Controlify, Debugify, Ixeris) one at a time; the issue persisted after each removal.
h3. Measurements, layer by layer
evdev: With W + Left Ctrl held (Ctrl pressed before, released after), I pressed Space × 6 during normal gameplay. The keyboard HID device ({{/dev/input/event4}}) shows all 6 down+up pairs delivered normally ({{MSC_SCAN}} raw={{0x7002c}}). The game registered 0 of 6, so the jump key vanishes (symptom: can't sprint-jump).
Combo tests:
** W + L-Ctrl + Space → 0/1
** W + R-Ctrl + Space → 0/1 (R-Ctrl is bound to nothing, which rules out sprint logic and isolates the Control modifier itself)
** W + L-Shift + Space → 1/1 (other modifiers don't trigger the swallow)
Conclusion: Keys reach the kernel intact. The loss happens inside the game's input path whenever {{ControlMask}} is active, consistent with this issue's mechanism: the SDL/IME layer is armed during gameplay even though no text field exists.
h3. GLFW-era workaround is inert on this stack
{{XMODIFIERS=@im=null}} (the old MC-122421 escape hatch) has no effect. I verified both {{@im=none}} and {{@im=null}} with full restarts, still 0/6. This matches SDL3's X11 IME integration using ibus over the DBus session bus rather than XIM.
h3. Note on the OpenGL root-cause analysis above
The snapshot-9 temporary-window analysis is Windows-specific (cached HWND). What the Windows data can't show: on X11 the mis-targeting happens regardless of IME state. Mine never visibly toggles (an ASCII engine can't compose), yet the swallow still occurs, so text-input arming is independent of whether an IME language is active.
I couldn't verify Vulkan here (the pack crashes on the Linux Vulkan path, unrelated), so whether Vulkan also avoids this on X11 is still open for someone else to test.
h3. Request
Could you fold the Linux/X11 + ibus path into this ticket's scope? A Windows-specific window-creation-order fix likely wouldn't touch X11, where the same state shows up as silent key loss rather than a toggling indicator. Enforcing {{SDL_StopTextInput}} whenever gameplay resumes from any non-text screen would cover ibus users with default ASCII setups as well.