Window.cursor_position can return Some when it shouldn't

[Plonq]

Bevy version

0.10.1

What you did

Called the Window.cursor_position method after moving mouse from one window to another.

What went wrong

It intermittently returns Some(...) when it should be None.

Additional information

Using the small app below, this video shows the issue clearly. You can see that sometimes, but not always, when moving the cursor from one window directly to another window, the first window still thinks it has the cursor. This results in multiple windows claiming they have the cursor, while only one can at any one time.

I can see here Bevy sets the cursor position to None when it sees a WindowEvent::CursorLeft event from winit, but I verified that it is fired every time, even when the issue occurs, so I don't believe this is a bug in winit.

Screen.Recording.2023-06-14.at.7.26.15.pm.mov

Minimal app:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                position: WindowPosition::At(IVec2::new(400, 200)),
                ..default()
            }),
            ..default()
        }))
        .add_startup_system(setup)
        .add_system(print_cursor_position)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn(Window {
        title: "Second window".to_owned(),
        position: WindowPosition::At(IVec2::new(0, 0)),
        ..default()
    });
}

fn print_cursor_position(windows_q: Query<&Window>) {
    for window in windows_q.iter() {
        println!(
            "Window '{}' cursor position: {:?}",
            window.title,
            window.cursor_position()
        );
    }
}

[Aceeri]

Just noticed this as well, put in a fix for it.

[Plonq]

After a little more digging, I've discovered the problem is that sometimes a WindowEvent::CursorMoved event fires after the WindowEvent::CursorLeft event, which sets the cursor's position back to Some. I thought maybe in the moved handler, we could update the position of the cursor only if the existing position is Some, but that's not viable because the only way the cursor position is updated is from WindowEvent::CursorMoved events. If WindowEvent::CursorEntered included a position, we could use that, but alas it does not.

This feels like a winit bug after all, since the out-of-order events are coming from there.