M3: closing PdfCraft while minimized no longer saves a 0 x 0 window

[mtlcl410]

What this changes

Closing PdfCraft while it is minimized (from the taskbar's "Close window", Alt+F4 on the taskbar button, or a sign-out) saved a window the next start could hardly use. eframe stores the window's settings just before App::save, from the window as it is then; Windows reports a minimized window as 0 × 0 at (-32000, -32000). egui-winit then opens the next start at its 64-point floor (clamp_size_to_sane_values) and clamps the position into the screen's corner. Found while testing on a 6K display at 225%: a 172 × 223 px window at (0, 0), and the 820 × 520 minimum size did not apply to the restored size. Reproduced on current main by minimizing and closing.

• window_state::WindowState (desktop only) remembers the settings eframe stored while the window was shown, starting from those it started with. In App::save, while the window is minimized, it puts them back; if there are none, it removes the entry so the next start opens at the default size.
• On the first frame whose size is known, a shown window at egui's floor in both directions (only reachable from such settings) gets 1440 × 920 points, at most nine tenths of the monitor, and the broken settings it started with are dropped. So people who already have such settings get a usable window once.
• apps/pdfcraft seeds the state from cc.storage. Nothing changes for a window closed while shown.

How you verified it

• cargo fmt --check; cargo clippy -p pdfcraft-ui-egui -p pdfcraft --all-targets -- -D warnings; cargo check -p pdfcraft-ui-egui --target wasm32-unknown-unknown (no new warnings)
• cargo test -p pdfcraft-ui-egui --lib window_state (3 tests)
• On Windows 11, 6016 × 3384 at 225%, with the app built from this branch, driving the real window (minimize with ShowWindow, close with WM_CLOSE) and reading app.ron:
  • main: minimize + close stores inner_size_points: (0, 0) at -32000, and the next start is 172 × 223 px;
  • this branch, from those settings: the window opens at 3268 × 2149 px; minimize + close then leaves no broken entry; the next start is the same size.

Tests. a_minimized_window_keeps_the_last_shown_settings and with_nothing_shown_yet_a_minimized_save_stores_no_window (with a map-backed eframe::Storage), and a_window_at_eguis_floor_gets_a_usable_size (a 64 × 64 window gets the size, an 820 × 520 one chosen by the user and a minimized one don't). The first fails if keep stops putting the settings back.

Never-crash

• No new unwrap/expect/panic! outside tests; no unsafe

Provenance

• No assets, fonts or copied code

🤖 Generated with Claude Code

https://claude.ai/code/session_01RUNQSPVXx3dDBabRZHAnjz

[FredApps]

Approving at head 39e1126, with one open CI question below.

Read the diff: WindowState::keep copies strings between storage keys and repair reads viewport info with let Some(rect) = rect else { return }. There is no indexing, unwrap or unsafe. The module is desktop-only (cfg(not(target_arch = "wasm32"))) and repair runs once. A minimized close restores the last shown settings, or removes the entry when none exist, and a window at egui's 64-point floor in both directions gets a usable size.

Validated on a Linux validation host (detached worktree at this SHA, 2 cargo jobs):

• cargo fmt --all -- --check: pass
• cargo test --locked -p pdfcraft-ui-egui --lib window_state: 3 passed, 0 failed
• cargo test --locked -p pdfcraft-ui-egui --test editing: 129 passed, 0 failed, 4 ignored
• cargo clippy --locked -p pdfcraft-ui-egui -p pdfcraft --all-targets -- -D warnings: pass
• cargo check --locked -p pdfcraft-ui-egui --target wasm32-unknown-unknown: pass
• cargo xtask layers: pass
• Red check: with keep no longer putting the shown settings back, a_minimized_window_keeps_the_last_shown_settings fails (window_state.rs:97).

CI note: the hosted test (windows-latest) check failed on image_pixels_follow_the_frame_while_a_corner_is_dragged (tests/editing.rs:4243, "the picture is drawn in the frame ... not only at []"). That test and the code it covers are not touched by this PR, it passes in my Linux run above, and the failure looks like a picture-not-yet-loaded timing race. I did not reproduce it on Windows or confirm it on main, so a maintainer should re-run that job.

Not verified: the real Windows minimize-and-close behaviour (I rely on the author's manual run), macOS and other Linux window managers, and the hosted CI checks other than as noted.

[FredApps]

Re-reviewed rebase30c174be9e723ff5f9039c47eb3ee5586283c278 against my prior approved39e11261575e55bf96d49e0ce4784781c304ca92. All three branch patches are unchanged apart from hunk positions; window_state.rs retains the exact blob. I checked the two upstream lib.rs changes (trusted certificate application and window title lookup) and found no new scoped interaction blocker. Hosted CI38893960807 succeeded. All three window_state tests and image_pixels_follow_the_frame_while_a_corner_is_dragged explicitly passed on Ubuntu and Windows. No new local test or real desktop minimize/close qualification was performed.