This issue also occurs in 26.3-pre-2 when using the Microsoft Chinese IME, and the IME candidate window appears even when pressing any key while no text input field is selected.

Can confirm in 26.3 RC-3

After consulting a mod developer, the following investigation results were obtained:

Background ①: When creating an OpenGL context, a window must be provided to bind to it.

Background ②: SDL internally and permanently caches the HWND of the first window created, for use by input method operations.

Background ③: In Snapshot 9, the timing of window creation changed from the original “create hidden window → create OGL context → show window” to “create OGL context → directly create visible window.”

In terms of implementation details, Snapshot 8’s OGL context binds directly to the real game window, whereas Snapshot 9 binds to a temporary window upon creation. This causes SDL’s cached HWND to become that temporary window, making it impossible to perform input method operations on the real game window created later.

In other words, under SDL, the first window created must be the real game window. The Vulkan backend, because it has no mandatory initialization requirement to bind to a window, does not have any temporary window.

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.