Fix FloatBar disappearing after minimization or monitor disconnect

[Juafeis]

Summary

• stop persisting FloatBar geometry while its native window is minimized
• reject Windows' exact minimized-window parking coordinates when restoring saved geometry
• verify restored/current FloatBar bounds against the work areas of all active monitors
• immediately move a live FloatBar onto the primary monitor if a display disconnect leaves it off-screen
• preserve legitimate negative multi-monitor origins by keeping every visibility check in physical coordinates
• cover minimized sentinels, disconnected monitors, negative monitor origins, and floating/taskbar fallback placement with focused tests

Problem and reproduction

There are two confirmed ways for the FloatBar to disappear while Show Floating Bar remains enabled.

Reproduction A: minimization

1. Open Settings > Menu and enable Show Floating Bar.
2. Use Show desktop (Win+D) so Windows minimizes/parks the FloatBar window.
3. Exit and reopen CodexBar.
4. Confirm that Show Floating Bar is still enabled, but the bar is absent from every monitor.
5. Inspect %APPDATA%\CodexBar\window_geometry.json.

Reproduction B: primary-monitor disconnect

1. Connect two monitors and make the monitor containing the FloatBar the Windows primary display.
2. Keep CodexBar and the FloatBar running.
3. Power off or disconnect that primary monitor.
4. Confirm that Windows switches to the remaining monitor but the FloatBar does not appear there.
5. Inspect %APPDATA%\CodexBar\window_geometry.json.

In the second reproduction, observed on CodexBar 0.42.0, Windows immediately changed the FloatBar entry to:

"floatbar": {
  "x": -32000,
  "y": -32000,
  "width": 211,
  "height": 40
}

The native FloatBar window was also reported as minimized. Removing only the invalid floatbar geometry entry and restarting CodexBar restored it on the remaining 1920x1080 monitor at (780, 8).

Root cause

The FloatBar window-event handler persisted every Moved, Resized, and CloseRequested event. On Windows, minimizing the window or disconnecting its monitor can park it at the physical coordinate (-32000, -32000). The startup path trusted that stored position, so a transient Windows window-management state became permanent application state.

The original guard only prevented that invalid state from being saved/restored. The primary-monitor disconnect reproduction also shows that the running window must be recovered immediately and that any other stale position from a disconnected display must be validated against the current monitor topology.

Fix

The persistence path now skips geometry when Tauri reports the window as minimized and strictly rejects the raw physical (-32000, -32000) sentinel.

The FloatBar now also checks its actual physical bounds against every active monitor work area:

• during startup geometry restoration
• when showing an already-created FloatBar
• after relevant move/resize events
• when applying FloatBar settings to an existing window

If it no longer intersects an active monitor, CodexBar unminimizes it when needed and moves it near the top or bottom center of the current primary monitor, preserving the selected FloatBar style. Because this check uses physical window and monitor coordinates end to end, legitimate layouts with negative origins such as (-8000, -8000) remain valid.

Validation

• cargo test -p codexbar-desktop-tauri — 312 passed
• cargo clippy -p codexbar-desktop-tauri --all-targets --no-deps -- -D warnings — passed
• cargo fmt --all — passed
• git diff --check — passed
• live recovery on the affected Windows machine: after removing the invalid FloatBar entry and relaunching, the bar is visible on the remaining active monitor and the saved position is (780, 8)

The repository-wide cargo clippy -p codexbar-desktop-tauri --all-targets -- -D warnings still reports two pre-existing collapsible_match warnings in rust/src/providers/claude/cli_reset.rs (lines 278 and 283); this PR does not touch that code.

[Finesssee]

Thanks for the PR, I will review this ASAP.

[Finesssee]

P2: outer_position() returns a PhysicalPosition, but the new predicate applies the logical-coordinate HiDPI range (-32000..=-6400) before the later pos / scale conversion. A legitimate multi-monitor origin such as physical (-8000, -8000) can therefore be classified as a minimized sentinel and skipped, so the FloatBar silently loses its saved position on that layout. Please either convert pos to logical coordinates before calling this helper, or make the helper strictly test the physical (-32000, -32000) sentinel; add a regression test using the same coordinate units as remember_geometry.

[Juafeis]

Good catch. Now the coordinate handling should be strict and unit-safe. remember_geometry now checks is_minimized() and only rejects the exact physical (-32000, -32000) sentinel; the restore path likewise rejects only the exact persisted sentinel observed in this bug. The scaled-range heuristic has been removed, so legitimate negative multi-monitor origins are preserved. I also added a regression test that verifies physical (-8000, -8000) is remembered.

[Juafeis]

Btw, something even more important I found: this is not limited to using Show Desktop or reopening CodexBar.

On my two-monitor setup, the FloatBar was on the Windows primary display. Simply powering that display off while CodexBar was still running caused Windows to mark the live FloatBar window as minimized and move it to the exact physical position (-32000, -32000). The second display became the active primary monitor, but the FloatBar stayed parked instead of moving across. So this can happen during completely normal use, without restarting or explicitly minimizing the app.

I have pushed the additional changes in f4ed1db. The fix now checks the FloatBar's real physical bounds against the work areas of all currently active monitors, both when restoring/showing it and when Windows emits move or resize events. If it no longer intersects any active monitor, CodexBar unminimizes it if necessary and places it on the new primary display. This also covers valid-looking but stale coordinates from a disconnected monitor, while preserving legitimate negative coordinates used by multi-monitor layouts.

I reproduced the failure on CodexBar 0.42.0, recovered the bar on the remaining monitor at (780, 8), and updated the PR description with the exact two-monitor reproduction steps. All 312 desktop Tauri tests pass, as does targeted Clippy with --no-deps -D warnings.

[Finesssee]

Request changes — thermo-nuclear + ponytail review

Direction is right: do not persist Windows park coordinates; relocate when the live window is off every connected display; cover show + settings reapply + move. Please address the blockers below before merge.

Blockers

1. Visibility must use full monitor bounds, not work area (floatbar/window.rs — ensure_visible_on_active_monitor)

   • Today “on-screen” means intersects some monitor work area.
   • Taskbar-style floatbar is intentionally placed in the reserved taskbar strip (existing show first-launch uses full monitor.size()).
   • A bar fully in that strip has zero work-area intersection and will be yanked to primary on every move/resize/apply_state.
   • Fix: split concerns —
     • Visibility / “still on a connected display” → intersect against monitor.position() + monitor.size() (full bounds).
     • Fallback placement → keep work-area + style-aware padding.

2. Do not Settings::load() on every Moved/Resized (floatbar/mod.rs)

   • Hot path hits disk+deserialize only to read float_bar_style, and style is only needed when relocation actually runs.
   • Fix: probe visibility first; load style (or default "floating") only inside the relocate branch; or thread style from an already-loaded snapshot on apply_state/show.

3. Stored-geometry reject is logical vs physical (HiDPI gap)

   • geometry_store stores logical coords (remember_geometry divides by scale).
   • is_windows_minimized_position documents exact physical (-32000, -32000).
   • At scale 1.25/1.5/2.0, previously parked geometry becomes e.g. -25600 / -21333 / -16000 and passes the exact check.
   • Fix: scale-aware / range-based reject (or reject if restored physical bounds do not intersect any monitor), and clear the bad entry when relocating. Keep live outer_position equality on physical -32000 as-is.

Non-blocking (preferred in same pass)

4. Prefer atomic relocate+persist in one call so the event handler does not rely on early-return + synthetic Moved to re-persist.
5. One shared default-origin helper for first-open and recovery (they already disagree: full monitor vs work area).
6. After unminimize + move, re-assert apply_no_activate / apply_always_on_top so recovery does not steal focus.
7. Add a unit test: “window fully in monitor bounds but outside work area remains visible” once (1) is fixed.

Ponytail (complexity only)

• Inline should_remember_physical_position (one-line wrapper).
• Collapse dual WebviewWindow/Window trait paste if &Window is enough.
• Drop style load from the hot path (same as blocker 2).
• Share placement formula with first-open.

Net: ~−30–50 lines possible after the above.

Please push an update addressing blockers 1–3 (and ideally the non-blocking items). Happy to re-review quickly after that.

[Finesssee]

Thanks for the original fix — the recovery direction was right.

We cannot push onto the fork branch (Juafeis:agent/fix-floatbar-minimized-position), so the review blockers are implemented on a maintainer branch that also rebases onto current main (incl. #197):

→ #200

Addressed from the request-changes review:

1. Visibility vs full monitor bounds (taskbar strip no longer forced-relocated)
2. No Settings::load() on every Moved/Resized — style only when relocating
3. HiDPI-aware stored logical park reject (≤ -15000 on both axes)
4. Atomic persist after relocate, shared default origin helper, apply_no_activate after recovery, extra unit tests

Please close this draft PR in favor of #200 when convenient, or say if you prefer to cherry-pick the tip commit onto your branch instead.

[Finesssee]

Closing as superseded by #200 (original fix + review blockers, rebased onto main).