The bug:
Opening the inventory and moving your cursor quickly sometimes doesn't make the cursor centered. Since this bug is very unpredictable it can really screw you up when you need to replace your popped Totem of Undying extremely quickly while you're PvPing someone.
Steps to reproduce ❓ :
I couldn't reproduce this bug since I don't really understand it, so I asked a mod developer who already fixed the bug for a mod about how to reproduce it. This is what he told me:
A stable trigger method of the bug: the game window lost its focus without any GUI opening, when it gains the focus again then open a GUI, the cursor will appear from where it was when the window gained the focus. Theoretically, if the cursor can move without a GUI opening, after locking the cursor again(by game input system) and then opening a GUI, the cursor will appear from where it was locked. This may occasionally happen when there is a "tick events traffic".
In fact, it seems the bug turns out to be a mistake made by GLFW's documentation - the Javadoc of method GLFW.glfwSetCursorPos() says it will only work when the cursor mode is CURSOR_DISABLED, but according to my experiments, this method actually only takes effect when the cursor mode is CURSOR_RELEASED. The Minecraft does try to center the cursor when opening a GUI, but when GLFW.glfwSetCursorPos() method is invoked by MC the cursor mode is CURSOR_DISABLED, so this action actually fails all the time. This mod just manually set the cursor mode to CURSOR_RELEASED before the invocation of Minecraft's cursor centering method.
Intended behavior:
The cursor should always be in the middle-uppermost slot when you open your inventory.
Actual behavior:
The cursor appears in a random spot in your inventory when you open your own inventory.
Linked issues
duplicates 1
Comments 4
I rewrote the bug report below but since I don't know anything about coding I'm not sure if this is good or not. The most important part is the steps to reproduce. The text below was written by ChatGPT so it may not be fully accurate, but it should give a clearer picture of what this bug is about:
1. The Bug: The cursor position in the game window does not reset correctly when opening a GUI after the window loses and regains focus. The bug occurs even when the game window does not lose focus externally. It is triggered when the cursor is locked, and a GUI is opened, resulting in an incorrect cursor position.
2. Steps to Reproduce: To reproduce the bug, follow these steps:
Launch the game and ensure the game window has focus.
Within the game, lock the cursor (using the game's input system or a specific key combination).
Open a GUI (e.g., inventory, settings) within the game.
Observe the cursor's position in the GUI.
3. Intended Behavior: The intended behavior is that when the cursor is locked and a GUI is subsequently opened, the cursor should appear from the position where it was locked. This behavior should occur consistently, regardless of whether the cursor was locked before opening the GUI or not.
4. Actual Behavior: The actual behavior is that when the cursor is locked and a GUI is opened, the cursor does not appear from the correct position. This issue is related to a discrepancy in the documentation of GLFW's GLFW.glfwSetCursorPos() method. According to the method's Javadoc, it is stated that glfwSetCursorPos() only works when the cursor mode is set to CURSOR_DISABLED. However, through experimentation, it has been found that the method only takes effect when the cursor mode is set to CURSOR_RELEASED.
In the case of Minecraft, the game attempts to center the cursor when opening a GUI. However, since the GLFW.glfwSetCursorPos() method is invoked by Minecraft while the cursor mode is CURSOR_DISABLED, the action fails to correctly reset the cursor position. As a workaround, a mod has been developed to manually set the cursor mode to CURSOR_RELEASED before invoking Minecraft's cursor centering method.
Please note that this bug report is based on the provided information, and further investigation or clarification may be required from the development team to fully address the issue.
> "The text below was written by ChatGPT so it may not be fully accurate"
Please do not write steps to reproduce using AI, or issue descriptions in general, as it cannot actually play the game and confirm issues with certainty. A video of you reproducing the issue, along with steps to reproduce that you have written would be very helpful, as I am unsure how to properly follow and confirm the described behavior.
Duplicate of MC-150164?