Skip to content

Keep the frame callback when a minimized window gets SIZE_MINIMIZED again - #24

Merged
kaylafortin merged 2 commits into
unity/hub-consolidatedfrom
unity/HUB-8707-keep-frame-callback
Nov 10, 2026
Merged

kaylafortin merged 2 commits into
unity/hub-consolidatedfrom
unity/HUB-8707-keep-frame-callback

Conversation

@kaylafortin

Copy link
Copy Markdown

On Windows, a minimized window that receives WM_SIZE(SIZE_MINIMIZED) a second time before it is restored never draws again. It keeps its last frame on screen, while input, cursor changes and native dialogs still work. Only a restart recovers it. Investigated for the native Unity Hub (HUB-8707, a Hub 4.0 beta report of a window that stopped updating after being open all day).

  • Before: the SIZE_MINIMIZED branch of handle_size_msg moved request_frame into restore_from_minimized unconditionally. On a second SIZE_MINIMIZED, request_frame was already empty, so None overwrote the parked callback. The restore had nothing to put back, and draw_window returned early on every later WM_PAINT.
  • Now: the callback is parked only when there is one to park.

Upstream gpui-ce main has the same code.

What is and isn't proven

  • Proven: the mechanism. In a debug Hub build, a second SIZE_MINIMIZED sent to the minimized window left it frozen after restore: the app state navigated, the screen did not. With this fix the same steps repaint.
  • Not proven: which real-world event sends the second message. On a Windows 11 machine with one display, none of these did: lock with the display off, sleep and wake, a display scale change, moving, resizing or minimizing again while minimized, or ShowWindow hide/show sequences on a minimized window. The fix is a no-op when the message does not repeat.

Testing

platform::tests::a_window_minimized_twice_still_draws_after_restore opens a real window with a counting frame callback, minimizes it, sends a second WM_SIZE(SIZE_MINIMIZED), restores it, forces a paint, and checks that the callback ran. Run on a Windows desktop session:

  • Without the fix it fails: the restored window never requests a frame.
  • With the fix it passes, and the full gpui_ce_windows lib suite passes (25 tests, test-support,render-to-image).

Like the other window tests it needs a desktop session.

cargo clippy -p gpui_ce_windows --all-targets reports nothing in the changed files; its existing findings (gpui_render/build.rs, directx_renderer.rs, direct_write.rs) are already on unity/hub-consolidated.

For Hub 4.0, unity/HUB-8707-keep-frame-callback-v4.0.0 carries the same commit on top of c25e0ae90c, the release/v4.0.0 pin.

🤖 Generated with Claude Code

…ZE_MINIMIZED again

`WM_SIZE(SIZE_MINIMIZED)` moved the frame callback into
`restore_from_minimized` without checking whether it was still there. A
second `SIZE_MINIMIZED` before the window was restored took the already
empty `request_frame` slot and stored `None` over the parked callback. The
restore then had nothing to put back, so every later `WM_PAINT` returned
before drawing: the window kept its last frame for good while input,
cursor changes and native dialogs still worked. Only a restart recovered it.

Park the callback only when there is one to park (HUB-8707).
`platform::tests::a_window_minimized_twice_still_draws_after_restore` fails
without the fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kaylafortin
kaylafortin marked this pull request as ready for review November 6, 2026 20:12
@kaylafortin

Copy link
Copy Markdown
Author

/harness-review

@kaylafortin
kaylafortin merged commit 29e33e0 into unity/hub-consolidated Nov 10, 2026
15 checks passed
@chris-addison
chris-addison deleted the unity/HUB-8707-keep-frame-callback branch November 11, 2026 20:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants