`ControlFlow` is ignored while window is being resized on Windows

[hecrj]

The ControlFlow set on the EventLoopWindowTarget is currently ignored on Windows while a window is being resized.

As a result, the EventLoop is not resumed when it should during the resizing process when WaitUntil or Poll are set as the control flow.

Other platforms are unaffected and work as expected.

[kchibisov]

I generally don't see what could be causing this, like the WM_SIZE handling is no different than anything else.

Would suggest to step with debugger or something like that before it tries to go back to polling.

[AustinMReppert]

This seems to be happening when interacting with the window buttons as well.

Recording.2023-12-20.092743.-.Trim.mp4

Recording.2023-12-20.055544.mp4

[kchibisov]

I mean, the only thing that is helpful would be debugging the wait_for_msg inside the windows backend, given that I generally don't have a way to debug due to hard to access windows hardware, it could take time until someone on windows try to look into it.

[dtzxporter]

Some more info:

dispatch_peeked_messages never returns after the DispatchMessageW(msg = WM_NCLMOUSEDOWN) until after the user releases the mouse.

WM_PAINT events continuously flow while it's paused there.

[msiglreith]

Some (long running) actions in Windows start modal event loops (e.g as mentioned resizing and non-client area interactions) on top of the current running event loop iteration. Before the event loop changes the Windows backend internally checked the control flow on WM_PAINT events to as sync points to handle control flow changes (feeding in NewEvent events and so on), but added quite some complexity. Redraws are now more decoupled from the normal event flow and don't act as these sync points anymore. I'm not sure what is the desired behavior to be fair.

Continous presentation should be possible by requesting redraws inside the redraw event to periodically schedule new paint events. (IIRC non-client area didn't work in the past and might need some internal handling to correctly trigger redraws)

[kchibisov]

@msiglreith I think the issue is that there's no resize at all now and the events are not sent to user? Though, it's hard to get that based on video (where you must hunt for log and could easily miss) and report saying that it's just broken.

Could you look into that when you have time?

[dtzxporter]

Yes, this is the issue. It will repaint because the window itself is receiving paint events but the dispatcher is still stuck waiting for the resize event to stop. No other events will flow back to the user at this time, which makes it impossible to do other things besides repaint while resizing, but normally you'd be able to (and other platforms work properly).

[msiglreith]

Posting an update on this as I tried a few things so far but couldn't come close to a proper fix so far.
I looked into the non-client control part primarily as this appears to be more strict compared to the resize border:

As mentioned, the root cause is that DefWindowProc starts to block on WM_NCLBUTTONDOWN and won't return unless user input happens:

Trying to wakeup this modal loop by manually scheduling a WM_PAINT, a timer to trigger WM_TIMER, or a custom event via PostMessageW doesn't work, the message may only be received afterwards.
Not calling DefWindowProc to manually, for example, call the SC_CLOSE syscommand allows to re-implement the close button behavior similar to the case where the client draws the system controls. But this is still not free of issues as the button hover rendering is incorrect then. SetCapture preserves the pressed-hover rendering once moving the mouse inside the non-client area but re-entering will break the rendering again..