Turning on GLFW_CURSOR_DISABLED when moving the mouse will produce huge mouse position offsets

[Intro1997]

Problem

Hello, I'm using the glfw 3.4 version by building with CMake. I found that when you set GLFW_CURSOR_DISABLED by glfwSetInputMode()in moving mouse, sometimes you will find that there is a big offset between the cursor position obtained from glfwGetCursorPos before and after glfwPollEvents is called. I test it on macOS 14.4, Windows 11 and Ubuntu 22.04 LTS, only ubuntu doesn't have this issue.

I found this issus may as same as #1523 and #2411, and when I remove _glfw.platform.setCursorPos(window, width / 2.0, height / 2.0); in _glfwCenterCursorInContentArea at input.c file, both macOS and Windows 11 are correct.

Reproduce Problem

I push a test project to reproduce this issue. You can play with tag v0.0.1-cursor_bug to check this issue.

And I also record a video to show what the issue looks like (using Bongo cat Mver to show my mouse and keyboard):

In this video, I print my cursor position by glfwGetCursorPos before and after glfwPollEvents is called when cursor is in GLFW_CURSOR_DISABLED state:

    if (glfwGetInputMode(window, GLFW_CURSOR) == GLFW_CURSOR_DISABLED) {
      glfwGetCursorPos(window, &cursor_x, &cursor_y);
      std::cout << "before poll cursor pos (" << cursor_x << ", " << cursor_y << ")\n";
    }
    glfwPollEvents();
    if (glfwGetInputMode(window, GLFW_CURSOR) == GLFW_CURSOR_DISABLED) {
      glfwGetCursorPos(window, &cursor_x, &cursor_y);
      std::cout << "after poll cursor pos (" << cursor_x << ", " << cursor_y << ")\n";
    }

win_cursor_bug.mp4

Let me describe what happens and when does this happen in video:

1. Show the basic interaction. (0:04~0:11)
2. After start moving my mouse to upper right corner, I set GLFW_CURSOR_DISABLED by press ctrl before stop moving mouse. And you can see the cube jumps to upper right corner immediately, then move back to center. Actually it should move to lower left corner.(0:15~0:17)
3. You can see the print message where the cursor hover at time 0:22: before poll events , the cursor position is (56, 529), and after poll events, the cursor position is (-288, 758). There is a huge offset between the two positions. (0:21~0:22)
4. At the 0:39~0:40, I do the same thing as 2 describes, and you can see that the cube obviously flashes in the upper right corner. (0:39~0:40)
5. At the 0:46, you can see a huge offset between two cursor positions, (89, 586) and (-222, 712). (0:46~0:47)

And macOS has the same issue:

mac_cursor_bug.mov

the cube jumps to the upper right corner then jumps back.

Expect Result

I also record a video which has a result that I expect (after remove _glfw.platform.setCursorPos(window, width / 2.0, height / 2.0); in _glfwCenterCursorInContentArea at input.c file):

correct_result.mp4

In this video you can see the cube always move but not jump.

Test Environment

1. Test Project: v0.0.1-cursor_bug of ICVp_test
2. macOS: macOS 14.4 (23E214) M3 Max
3. Windows: Windows 11 Pro 23H2 22631.3296

What I want

1. I want to know is this a bug ?
2. I want to know what happens here, why the result in Ubuntu is different with others? (I am new to client development)