luan_wo_xin_zhe

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.

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.

This might be the cause of the issue: "The third-person view camera has a collision that collides with block visual box. This can obstruct the player's vision with a close-up view in some situation where solid blocks are placed behind or in front of the player."

https://minecraft.wiki/w/Third-person_view

The third-person camera is by default located 4 blocks in front of or behind the player, but if the player suffocates in this mode, the distance seems to become 0 blocks. This can be confirmed by entering the following command:

/attribute @s minecraft:camera_distance base set 0

The software I use does not affect game performance.

My "Controls" settings remain at the game's default values and have not been changed.

@clamlol

This is the same issue as MC-91132, isn't it?

@clamlol

This is the same issue as MC-308804, isn't it?

During the period from 26.3 Snapshot 4 to 26.3 Snapshot 8, the issue was fixed. Starting from 26.3 Snapshot 9, the issue reappeared (the Microsoft IME has no problem, but the third-party input methods have problems).

Request to reopen this issue. In 26.3 Pre-Release 1, among the input methods I have installed, only the Microsoft IME has been fixed; the other two third-party input methods still have issues.

MC—311034：Regardless of whether Exclusive Fullscreen is enabled or disabled, Minecraft always enters Exclusive Fullscreen mode when fullscreen is enabled.

MC-311034 may cause this.

MC—311034：Regardless of whether Exclusive Fullscreen is enabled or disabled, Minecraft always enters Exclusive Fullscreen mode when fullscreen is enabled.

MC-311034

Why are the Mojang Priority different?

Issue update: In 26.2, the system input method is always used, and the emoji panel displays normally; after using the game's built-in IME in the 26.3 snapshots, the emoji panel completely fails to display, and other keys do not respond unless the Esc key is pressed.

你写错了，是 Sogou，不是 Sougo。

English： You wrote it wrong — it's Sogou, not Sougo.

This issue is a duplicate of MC-311297.

我可以复现这个问题，我肯定这个问题是存在的。

English: I can reproduce this issue, and I am sure that this problem exists.

我发现，在没有打开任何文本输入框的情况下，按潜行键，电脑系统右下角的“英”换成“中”，或者“中”换成“英”

English: I found that when no text input field is open, pressing the sneak key causes the input method indicator in the bottom-right corner of the computer to switch from "English" to "Chinese", or from "Chinese" to "English"

It looks like I accidentally chose "No one" for sharing my issue. What do I do now?

In the 26.3 Snapshot 4, this issue appears to have been resolved.

Mojang said, switched the library from GLFW to SDL3.