[Windows] Opening the window system menu or right clicking the title bar freezes the event loop

[filnet]

No description provided.

[filnet]

https://stackoverflow.com/questions/18041622/how-do-i-stop-windows-from-blocking-the-program-during-a-window-drag-or-menu-but

[aloucks]

Related: #894

[filnet]

@aloucks Yep.

In this PR the event loop will freeze:

• when pressing the left mouse button on any title bar button (window icon, minimize, maximize, close)
• when pressing the right mouse button anywhere on the title bar
• while the window menu is open (either by left clicking the window icon or right clicking anywhere in the title bar).

[aloucks]

I think this was closed by accident:

Relates to but does does not fix #1484

[filnet]

Issue is still there. Please reopen this issue.

[filnet]

Ping

[Osspial]

I was hoping that #1496 would fix this, but it actually seems to make it worse - with that, the event loop doesn't resume until the window gets resized. I'll take a look at figuring out why that happens.

[Osspial]

I'm pretty sure this is related to #894.

[mooman219]

We can detect when we enter this frozen state via WM_ENTERMENULOOP, WM_EXITMENULOOP, and WM_ENTERIDLE . Can't we just kick ourselves and fire events in this state?

This works for example while retaining a working context menu:

winuser::WM_ENTERIDLE => {
    let mut message: MSG = zeroed();
    while PeekMessageW(
            &mut message as *mut MSG,
            window_handle,
            0,
            0,
            PM_NOREMOVE,
        ) == 0
    {
        fire_event(MainEventsCleared);
    }
    SUCCESS
}

This doesn't cover the other cases where freezes happen, but this is definitely one of them.

[madsmtm]

From the Bevy discord:

when you you right click the title bar to get the menu (or pressing and holding the min/max buttons), you enter the modal loop where your application is completely frozen. This isn't a winit bug per-se, but an architecture design challenge. There is no way to resolve this without running code in a different thread (other than trying something exotic with the Windows Fibers API). I mention the Fibers API because there's an open PR in GLFW attempting to solve the same problem with Fibers. The PR is quite old at this point and was not merged. The general consensus that I've seen is to always run the simulation/render logic in a separate thread from the event loop. Elmindreda (the GLFW maintainer) has given that feedback in the past. Attempting to resolve the issue with Fibers would definitely be in Winit though, not in Bevy. I don't know if Fibers would even fully solve the problem since it was never merged. GLFW/Fibers PR: glfw/glfw#1426