Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ending a dragging operation basically never updates the cursor shape #88678

Open
MewPurPur opened this issue Feb 22, 2024 · 1 comment
Open

Comments

@MewPurPur
Copy link
Contributor

MewPurPur commented Feb 22, 2024

Tested versions

4.2.1, but this has been a longstanding issue

System information

Godot v4.2.1.stable - Pop!_OS 22.04 LTS - X11 - GLES3 (Compatibility) - Mesa Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i5-1235U (12 Threads)

Issue description

2024-02-22.20-46-35.mp4

Steps to reproduce

Do any of the actions above, which should automatically change the mouse cursor when you end dragging. But instead, they only do after you move the mouse around.

Minimal reproduction project (MRP)

It can be replicated in many places in the editor, as shown.

@Sauermann
Copy link
Contributor

Currently changing the mouse cursor is done by sending a mouse motion input event to the window. (See Window::update_mouse_cursor_state)

Doing it this way has caused in some cases crashes (See #69318). That is why I am reluctant to simple call update_mouse_cursor_state() in the relevant places, where the mouse cursor doesn't update automatically.

In order to resolve this fully, it becomes necessary to change update_mouse_cursor_state so that it doesn't create a new mouse move input event.
The first step to achieve this was done in #67791, which introduced Viewport::_update_mouse_over to adjust the Control/Window, that the mouse is over independently from input processing.

When I tried to solve the problem of this bug-report a few months ago, I came to the conclusion, that replacing the update_mouse_cursor_state implementation so that it directly accesses the currently hovered Control/Window requires additionally the function Viewport::get_section_root_viewport, which will hopefully get introduced by #67531. So my intention is to address this bug-report after that PR gets merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants