[cheng-block]

Scope: fix how the main window restores its saved size after the monitor it was saved on is unplugged and the remaining monitor has another scale. Non-goals: storing the scale in the state file (tauri-plugin-window-state stays the only writer), plugin version changes, onboarding geometry. Production diff is 34 added and 10 removed lines in src-tauri/src/window_state.rs, plus tests. The case with several monitors left needs more logic and is handled in a follow-up PR that builds on this one. It and the remaining limitations are listed under Known gaps.

What was wrong

Quit Buzz with the window on a 1x external monitor, unplug it, and relaunch on a 2x laptop. The window comes back at half size, at or below the 480x400 minimum. The plugin then saves that small size, so later launches keep it.

Why

The plugin saves size in physical pixels. A 602x470 window saved at 1x is 301x235 points at 2x, below minWidth/minHeight in tauri.conf.json. macOS does not clamp a programmatic resize to the minimum (tao platform_impl/macos/util/async.rs:88-101), so it can open below it; a later user resize is clamped to it.

• When no monitor contains the saved rect, reachable_client (src-tauri/src/window_state.rs:215-220 on main) moves the window onto the primary monitor but keeps the physical size.
• When the external sat to the right of the laptop, the saved rect can still fall inside the laptop's physical rect (3024 px wide at 2x), so it counts as reachable and is restored as saved.
• In the fallback case, the planned rect is in the fallback monitor's physical pixels, but tao's macOS and GTK setters convert physical values with the window's current scale (tao 0.37.2 platform_impl/macos/window.rs:702-731, platform_impl/linux/window.rs:472-510). When Buzz starts on a monitor with another scale, the window lands at the wrong size and place.

Separately, restore_geometry_from resized before it moved (window_state.rs:158-159 on main). On Windows, moving to a monitor with another DPI rescales the window (tao platform_impl/windows/event_loop.rs, WM_DPICHANGED), which undoes a resize sent first. The plugin's own restore_state moves first.

What changed

• restore_request gets the fallback monitor's scale and the main window config, and stays pure. If the saved size is below the configured minimum at that scale, it was saved at a lower scale, and it gets the configured default size (1200x800) instead, still capped to the work area and horizontally centered at its top. The minimum is converted to pixels with the rounding tao uses.
• On Windows tao applies the minimum to Buzz's undecorated frame, and the shadow insets come off the saved client (tao platform_impl/windows/event_loop.rs:1783-1810, :2124-2130), so a window at the minimum is saved below it (464x391 at 100%). The check there compares with that client: the rounded minimum minus the insets calculate_insets_for_dpi computes (windows/util.rs:419-447) with default metrics (4 px size frame plus 4 px padded border, scaled by DPI) and the Windows 11 top inset.
• Windows 10 has no top inset, so its client is taller and still passes (a Windows 10 save up to that one pixel short of its own client also passes). Anything below the Windows 11 client is replaced, since tao does not clamp a programmatic resize on Windows either (it answers WM_WINDOWPOSCHANGING without DefWindowProc, windows/event_loop.rs:1145).
• A sub-minimum size is replaced when the saved rect is unreachable, and also when only one monitor is left, since that monitor's scale is known even if the rect still falls inside it. With more monitors attached, a reachable rect is kept as saved.
• A relocated window is sent in the fallback monitor's logical units on macOS and Linux. Windows keeps physical values, since its monitor and window positions are true physical pixels.
• set_position now runs before set_size.

Known gaps

Handled in a follow-up PR that builds on this one (opens after this one merges):

• Two or more monitors left after unplugging, with the saved rect still inside one of them. Example: a 2x laptop and a second 2x monitor remain after a 1x external is unplugged. The rect stays reachable, so this PR keeps it as saved and it opens at half size, at or below the minimum. The follow-up keeps a rect only if a monitor under its header has a scale at which the saved size meets the minimum, and still keeps a header that spans a 1x and a 2x monitor.

Not fixed here or in the follow-up:

• When the saved monitor is gone, its scale is unknown, so only a size that would fall below the minimum is replaced. A window saved at 960x800 pixels or larger on a 1x monitor is still at least the minimum at 2x and opens at half its points; the default 1200x800 opens at 600x400 points. A 2x window resized to 600x400 points saves the same numbers, so the two cannot be told apart.
• Exact geometry when the saved monitor is still attached, the saved rect is reachable, and its scale differs from the monitor Buzz starts on. On macOS each monitor's physical rect is its point rect times its own scale, so rects overlap when scales differ. A 1x external to the right of a 2x laptop overlaps the laptop's 0 to 3024 px range, and a saved rect there has two valid readings, one per monitor. Monitor rects alone cannot tell which one was meant without the scale at save time, which only the plugin could store.
• A Windows machine with a wider window border than the default (user-wide SM_CXSIZEFRAME / SM_CXPADDEDBORDER) saves a smaller client at the minimum, so a window dragged to the minimum there is reset to the default size. Reading tao's get_frame_thickness would cover it; this PR assumes the default.

How verified

• New tests:
  • saved_size_is_kept_with_monitors_attached_and_recovered_on_a_lone_monitor
  • fallback_uses_default_size_when_saved_size_is_below_minimum_at_its_scale
  • minimum_allows_windows_shadow_insets_but_a_lower_scale_size_is_replaced: Windows minimum clients at 100%, 125% and 200% are kept only on Windows, and one pixel under them is replaced everywhere. A 1x save of 900x750 on a 2x laptop is replaced everywhere. At 110 and 100 DPI the rounded minimum and the Windows client are checked on both sides. A minimum saved one step lower, including 225% to 250%, is replaced everywhere.
• Existing restore_request tests now also check whether the window was relocated and at which scale.
• Removing the lone-monitor rule, the default size, the fallback scale in the result, the rounding, either Windows inset, or the top inset each makes at least one of them fail.
• The Windows branch was also run on macOS by forcing cfg!(windows) to true; CI runs only the host's branch.
• bin/cargo test -p Buzz --lib --locked window_state -- --skip onboarding_snapshot_is_kept_until_next_launch_restore: 15 passed. That skipped test segfaults on macOS on unmodified main too. It calls ns_window() through MockRuntime.
• bin/cargo clippy -p Buzz --lib --tests --locked -- -D warnings, bin/cargo fmt --all --check and git diff --check pass.
• MockRuntime geometry setters are no-ops, so neither the call order nor the logical-unit conversion has automated coverage. The in-app check below covers the macOS fallback path. The Windows inset values follow tao's code and the default metrics but were not measured on a Windows machine.

In-app check

Build: this PR at 94bc460e5 (later commits only rerun CI and merge main; no code change), #2402, #2403 and #2404, merged locally onto main at cb8c971e9. Run as the macOS desktop app with BUZZ_DEV_VIEWER= just desktop on a 2x laptop with two 1x external monitors. Window bounds were read from the window server (CGWindowListCopyWindowInfo), not by eye.

• Setup: I quit with the window on a 1x external. The saved state was 1201x714 pixels, below the 800 pixel minimum height at 2x. Then I unplugged both externals, leaving only the 2x laptop (1728x1117 points).
• First relaunch: Buzz used the one-shot onboarding snapshot instead (onboarding-window-restore.json is used once, then deleted). That snapshot was about 1720x1410 pixels at 1x, so the window opened at 860x705 points. That is above the minimum at half the points, the first "Not fixed here or in the follow-up" case under Known gaps.
• I quit, put back the state saved on the 1x monitor, and relaunched. The window opened at 1200x800 points at (264, 33), horizontally centered under the menu bar.

buzz-review-completed

[joahg]

🤖 Read the restore/relocate logic and tests; the sub-minimum fallback only triggers when the saved size is below the min at the fallback scale, so normal restores are unchanged. Windows-specific shadow-inset math is only covered by cfg-gated asserts, worth a hand check on Windows.

[wesbillman]

🤖 Carl, an automated reviewer, commenting via Wes’s GitHub account.

No blockers found in source review. Two independent reviewers checked restore order, the sub-minimum fallback, the logical conversion, minimum rounding and the Windows shadow slack against tao 0.37.2 and the locked tauri-plugin-window-state 2.5.0. Neither found a regression beyond the limitations the PR already discloses. For the repaired normal-window case, the plugin tracks the resize and reads current geometry on close, so it shouldn't re-save the bad size.

Validation gap: this is source-checked only. Windows native validation is skipped in CI, and no one has reproduced it on hardware. Before merge it's worth one real run on macOS: quit on a 1x external monitor, unplug it, relaunch on a 2x laptop, then quit and relaunch again to confirm the size persists.

[cheng-block]

Before merge it's worth one real run on macOS: quit on a 1x external monitor, unplug it, relaunch on a 2x laptop, then quit and relaunch again to confirm the size persists.

Ran it on macOS with this branch. Window state saved small and off the laptop, relaunched on the 2x laptop: it opened at 1200x800 points, centered under the menu bar. Quit, then relaunched with only the laptop attached: still 1200x800 at the same spot, so the size persists. Bounds read from the window server, not by eye.

While doing this I also relaunched once with the 1x externals still plugged in. That hits the attached-monitor gap in the description: the window grew to fill the laptop and was saved larger on quit. It comes from the existing reachable path converting physical pixels at the startup monitor's scale, which this PR does not touch.