Fix Windows fullscreen for multi-window Flutter views

[caoccao]

Summary

Fixes a Windows fullscreen rendering issue in desktop_multi_window sub-windows when another plugin, such as window_manager, changes the native window style and size for fullscreen.

The observed failure was that the Flutter content stayed at its previous windowed size in the top-left corner after entering fullscreen, while the rest of the monitor could show stale/underlying desktop windows instead of the app background. In some fullscreen paths this could also hang or freeze the app.

Branch: bugfix/windows-fullscreen-patch

What Changed

• Set Windows sub-window Flutter engines to flutter::UIThreadPolicy::RunOnSeparateThread.
• Refactored child Flutter view resizing into ResizeChildContent().
• Added a deferred child resize message after WM_WINDOWPOSCHANGED and WM_DPICHANGED, so the hosted Flutter child is re-sized to the updated client area after native fullscreen/window-position changes settle.
• Added a small pending-message guard so resize messages are coalesced and the flag is cleared if PostMessage fails.

Touched files:

• packages/desktop_multi_window/windows/flutter_window.cc
• packages/desktop_multi_window/windows/win32_window.cpp
• packages/desktop_multi_window/windows/win32_window.h

Why

desktop_multi_window creates each sub-window with its own native parent window and hosted Flutter child view. On Windows, entering fullscreen through window_manager.setFullScreen() changes the top-level window style and position/size. The existing WM_SIZE path resized the child in normal cases, but fullscreen style/position transitions could leave the child surface at the old windowed bounds for the frame that mattered, producing a top-left-only Flutter view.

The deferred resize keeps the normal immediate WM_SIZE handling, while also scheduling a follow-up resize after native window-position changes. That avoids a force-refresh style workaround and makes the child view match the final fullscreen client area.

The separate UI thread policy avoids recent Windows fullscreen freezes seen when fullscreen style changes are driven through platform-channel calls.

Validation

I've verified this patch in my flutter app and it works well.

Notes

This patch is intentionally Windows-only and scoped to the desktop_multi_window native sub-window wrapper. It does not change Dart APIs or behavior on macOS/Linux.

[Copilot]

Pull request overview

This PR targets a Windows-only rendering issue in desktop_multi_window sub-windows where the hosted Flutter view can remain at its prior windowed size after fullscreen/style transitions (e.g., when driven by window_manager), sometimes leading to stale desktop content showing or freezes.

Changes:

• Introduces a deferred child-view resize mechanism by posting a coalesced “resize child content” message after window position changes.
• Refactors child Flutter view sizing into a dedicated ResizeChildContent() helper (reused from multiple message paths).
• Sets sub-window Flutter engines to flutter::UIThreadPolicy::RunOnSeparateThread to avoid fullscreen freezes during style changes.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
packages/desktop_multi_window/windows/win32_window.h	Adds private helpers/flag to support coalesced deferred child-content resizing.
packages/desktop_multi_window/windows/win32_window.cpp	Implements deferred resize message + refactors child sizing into ResizeChildContent(); queues resize after DPI and window-position changes.
packages/desktop_multi_window/windows/flutter_window.cc	Sets Flutter engine UI thread policy to run on a separate thread for sub-windows.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[boyan01]

LGTM, thanks for the PR