Fix HUD overlay blocking the screen while recording - #845
Conversation
While a recording is active, getHudOverlayBounds() passed `isHudOverlayMousePassthroughSupported() && !hudOverlayRecordingActive` as the "passthrough supported" argument. On macOS and Windows this evaluated to false during recording, so the HUD was given the *fallback* geometry -- a fixed 860x540 (or 160px compact) block intended for platforms that cannot make the overlay click-through at all. That left a large, real window sitting over the screen for the whole recording: - The macOS window picker (Cmd+Shift+5) highlighted and selected the HUD instead of the window behind it, so that region could not be captured. - Any moment the renderer legitimately held the mouse (hovering the bar or the webcam preview), the entire block swallowed clicks rather than just the visible controls. - The floating webcam preview could only be dragged within that block, since it is positioned by a CSS transform inside the overlay window. Meanwhile setHudOverlayMousePassthrough() used the real platform check, so the window got fallback bounds with passthrough-style mouse handling -- the two paths disagreed about which mode the overlay was in. Whether the overlay can pass clicks through is a property of the platform, not of whether a recording is in progress, so use the platform check alone. Platforms without passthrough support keep the fallback geometry exactly as before; this only affects the recording case on platforms that already use a click-through overlay when idle. Verified on macOS 15 (arm64) by instrumenting the overlay window: across 204 samples during an active recording the bounds stayed at the full work area (1710x997) and setIgnoreMouseEvents was true for 168 of them, flipping to false only while the pointer was over the bar or the webcam preview. Before the change that same window was the 860x540 block. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesHUD overlay bounds
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🔵 Low · up to The fix removes the large recording-time HUD block on supported platforms, restoring access to the screen behind it. A bounded lifecycle edge case remains: if the HUD is recreated during recording, it may temporarily capture input across the work area and obstruct other applications. The change is mergeable with explicit owner awareness and follow-up to enforce passthrough during recreation. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Description checkExplanation The description clearly explains the problem, cause, fix, platform-specific behavior, and verification results. It does not use the template headings and omits the checklist, related issue, and screenshots or video, but it provides the critical information needed for review.
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
1 participant
Problem
While a recording is active, the HUD overlay becomes a large, real window sitting over the screen. In practice this means:
Cause
getHudOverlayBounds()passed this as the "passthrough supported" argument:On macOS and Windows that evaluates to
falseduring recording, so the HUD is handed the fallback geometry — a fixed 860×540 (or 160px compact) block intended for platforms that cannot make the overlay click-through at all.Meanwhile
setHudOverlayMousePassthrough()uses the real platform check, so the window ends up with fallback bounds but passthrough-style mouse handling. The two paths disagree about which mode the overlay is in.Fix
Whether the overlay can pass clicks through is a property of the platform, not of whether a recording is in progress — so use the platform check alone.
Platforms without passthrough support (Linux) keep the fallback geometry exactly as before. This only changes the recording case on platforms that already use a click-through overlay when idle.
Verification
npm test— 1022 tests pass.tsc --noEmitandbiome checkclean.Verified on macOS 15 (arm64) with a packaged build by instrumenting the overlay window and logging its real state every 500ms during an active recording:
1710×997(full work area)setIgnoreMouseEventstruein 168 / 204 samplesThe 36 samples with passthrough off all correspond to the pointer being over the bar or the webcam preview, which is the intended behaviour. Manually confirmed afterwards that the screen behind the HUD is clickable during a recording and the webcam preview can be dragged anywhere on screen.
I couldn't reproduce on Windows or Linux — the code path is shared with macOS on Windows, and Linux is unaffected by construction, but a second pair of eyes on Windows would be welcome.
Summary by CodeRabbit