Objective

WindowsWindowInner::handle_cursor_changed checks whether any cursor was already set and skips the SetCursor call. This makes changes between different CursorStyle variants to be ignored.

This was probably not noticed yet because Windows' WM_SETCURSOR message is usually dispatched on every mouse movement, so WindowsWindowInner::handle_set_cursor ends up setting the correct cursor shortly after. However, since GPUI unconditionally calls SetCapture on WM_[LRM]BUTTONDOWN messages, the WM_SETCURSOR message stops being dispatched while the mouse is down, causing the bug to surface as making it impossible to ever change the cursor while the user's dragging the mouse (even if there's no cx.active_drag or active captured hitbox).

Solution

We can unconditionally call SetCursor from WindowsWindowInner::handle_cursor_changed. This shouldn't be problematic, since WindowsPlatform::set_cursor_style already checks whether the cursor already changed before dispatching WM_GPUI_CURSOR_STYLE_CHANGED (which is the only path to handle_cursor_changed being called in the first place).

Linux and MacOS do not show this behavior and already allow cursor changes during drags.

Testing

I've only manually tested it; I don't know how we'd add a test for this behavior.

Any app with div().cursor(CursorStyle::SomeCursor) or window.set_cursor_style() calls is affected by being unable to set cursors while the mouse is clicked.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• N/A