fix(hud): keep the bar in place across a vertical↔horizontal flip

[EtienneLescot]

Summary

Switching the recording bar to the vertical layout and back no longer walks it up the screen.

Right after hud-overlay-set-size, the HUD's ResizeObserver fires again while the old viewport is still laid out. The hud-overlay-content report that follows therefore carried a stack rect measured in the window the main process had just replaced, and the main process stored it as the anchor. The next flip re-anchored on that stale rect: the window kept its top-left instead of the bar's bottom-centre, and the bar moved up by about 130 DIP each round trip.

The stack is always centred and pinned HUD_BAR_BOTTOM above the bottom edge, which is already how grantedContent is computed. The reported rect now uses the same formula on the allocated size. Only its size still comes from the measurement.

Related issue

Fixes #951

Type of change

• Bug fix

Release impact

• Patch

Desktop impact

• Windows
• macOS

Linux is unaffected: there the main process ignores the content rect (HUD_CLAMPS_CONTENT).

Testing

• Root cause. Hooked hud-overlay-set-size and hud-overlay-content in the main process of the packaged 2.0.0-rc.1 build (--inspect). The stale report [427,99,54,577] arrives right after set-size 648×826; it is the vertical bar centred in the old 908×697 window. The next flip lands exactly on the drifted bounds 432,19.

• After the fix, dev build, same hooks, Windows 11 at 125 %, two vertical↔horizontal round trips:

  	HUD bounds (DIP)	Bar centre x	Window bottom
  Start	316,149 908×697	770	846
  After round trip 1	302,149 937×697	770.5	846
  After round trip 2	302,149 937×697	770.5	846

  x moves from 316 to 302 only because the bar widened; it stays centred on the same point. No stale content report arrives any more.

  The flips were driven by DOM clicks on the layout button. The drift reproduced the same way on the unfixed rc.1 build, so the comparison holds, but this is not a check that the button is reachable with a real pointer.

• Regression test. LaunchWindow.test.tsx › "reports an opened popover as part of the rect kept on screen" now expects the rect computed from the allocation, not the stubbed (0, 0). It fails with the fix reverted.

• npx tsc --noEmit and npx tsc -p tsconfig.test.json --noEmit pass; npm run test: 4023 passed.

Summary by CodeRabbit

• Bug Fixes
  • HUD content and popover positioning now reflect the current window dimensions after resizing, keeping the content aligned within the allocated window. The popover remains horizontally centered and positioned relative to the window’s bottom edge, even when layout measurements have not yet updated to the latest viewport.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Repository guideline files applied to this review (1)

AGENTS.md — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: f1e71ad5-7e5d-4ad7-8af1-8d384738b9a8

📥 Commits

Reviewing files that changed from the base of the PR and between e04943a and 6b1e56a.

📒 Files selected for processing (2)

• src/components/launch/LaunchWindow.test.tsx
• src/components/launch/LaunchWindow.tsx

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

The HUD content rectangle now derives its position from the allocated window size. The test checks the stack’s centered horizontal position and bottom-anchored vertical position against the latest allocation.

Changes

HUD resize positioning

Layer / File(s)	Summary
Calculate and verify allocated content bounds src/components/launch/LaunchWindow.tsx, src/components/launch/LaunchWindow.test.tsx	contentFor calculates the stack position from the window size for both current and granted content rectangles. The test checks the position using the latest allocation and stack dimensions.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: my-denia

Merge Risk: ⚪ Minimal · up to 6b1e5

The HUD reports content bounds from the latest window allocation, and no actionable merge risk remains.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 6b1e5

The change is limited to recording-bar positioning and does not expand permissions or external access. No new security issue was identified. Recovery when a requested resize is not applied remains unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed values influence the existing desktop HUD window's positioning and stored content anchor. The inspected producer-to-consumer path introduces no new caller, IPC channel, credential access, or downstream authority.

Trust Boundaries and Controls

• observed — Geometry crosses the existing renderer-to-native boundary as numeric data. Native parsing and bounds application remain in place. These handlers validate geometry but do not establish sender authentication; this PR neither adds callers nor changes that existing boundary behavior.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the HUD positioning bug across vertical and horizontal layout flips.
Description check	✅ Passed	The description explains the root cause, fix, linked issue, affected platforms, testing results, and regression coverage. It does not include screenshots or video for the UI change, but the detailed t…
Linked Issues check	✅ Passed	Issue #951 requires the reported HUD content rect to use the allocated window position and the measured stack size. LaunchWindow.tsx now computes both currentContent and grantedContent with `con…
Out of Scope Changes check	✅ Passed	The pull request changes only HUD content-rect calculation in LaunchWindow.tsx and its regression test in LaunchWindow.test.tsx. These changes support issue #951. No unrelated product behavior or …
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}