fix(hud): stop the recording overlay from swallowing clicks - #797
Open
iOSDevSK wants to merge 1 commit into
Open
fix(hud): stop the recording overlay from swallowing clicks#797iOSDevSK wants to merge 1 commit into
iOSDevSK wants to merge 1 commit into
Conversation
While recording, the HUD overlay traded its full-work-area click-through window for a fixed 860x160 rectangle (860x540 with the webcam preview) anchored bottom-centre, with mouse events enabled on the whole window. Its transparent margins swallowed every click aimed at the app being recorded -- a Save button near the bottom of the screen simply did not respond. Dragging the bar only translated content inside that window, so moving the controls never freed the blocked area. The compact fallback exists because focus changes on Windows corrupt the WS_EX_TRANSPARENT flag behind setIgnoreMouseEvents forwarding, which would leave the stop button unclickable. Scope it to win32 and keep the click-through overlay everywhere else; macOS has no such failure mode and its renderer is already written for the full-work-area model. Also move the interactive box off the static column onto the transformed wrapper: transforms do not move layout boxes, so a pointer-events-auto parent kept eating clicks at the bar's original position after it was dragged away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
📝 WalkthroughWalkthroughThe HUD now forces compact fallback mode only during active Windows recordings. Windows overlay bounds and mouse passthrough transitions use this condition. Pointer handlers now follow the transformed HUD bar. ChangesHUD recording fallback
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant RecordingState
participant WindowsOverlay
participant HUDOverlay
RecordingState->>WindowsOverlay: report recording state transition
WindowsOverlay->>WindowsOverlay: evaluate recordingForcesHudOverlayFallback
WindowsOverlay->>HUDOverlay: apply compact bounds and interactive mode
WindowsOverlay->>HUDOverlay: restore expanded bounds and click-through mode
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@electron/windows.ts`:
- Around line 314-317: Update getHudOverlayBounds() or its
shouldExpandHudOverlayFallback() decision so recordingForcesHudFallback() always
forces compact bounds, regardless of active recording or visible webcam preview.
Preserve normal expansion behavior when the Windows fallback is not forced, and
add a regression test covering an active Windows recording with a visible webcam
preview.
- Line 213: Update the overlay bounds-selection logic around
isHudOverlayMousePassthroughSupported() so Linux retains full-work-area
click-through behavior instead of always selecting compact fallback bounds.
Implement the Linux-specific click-through path, or exclude Linux from the
fallback contract while preserving the intended full-work-area overlay
objective.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 2f1a1d17-d05a-46d9-80c7-89d50f9f22b4
📒 Files selected for processing (4)
electron/hudOverlayBounds.test.tselectron/hudOverlayBounds.tselectron/windows.tssrc/components/launch/LaunchWindow.tsx
| return getHudOverlayWindowBounds( | ||
| workArea, | ||
| isHudOverlayMousePassthroughSupported() && !hudOverlayRecordingActive, | ||
| isHudOverlayMousePassthroughSupported() && !recordingForcesHudFallback(), |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Keep the full-work-area overlay on Linux.
isHudOverlayMousePassthroughSupported() returns false on Linux. Line 213 therefore always selects compact fallback bounds on Linux. recordingForcesHudFallback() returning false cannot preserve the full-work-area overlay.
Implement a Linux full-work-area click-through path, or remove Linux from this fallback contract and the PR objective.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@electron/windows.ts` at line 213, Update the overlay bounds-selection logic
around isHudOverlayMousePassthroughSupported() so Linux retains full-work-area
click-through behavior instead of always selecting compact fallback bounds.
Implement the Linux-specific click-through path, or exclude Linux from the
fallback contract while preserving the intended full-work-area overlay
objective.
Comment on lines
+314
to
317
| if (recordingForcesHudFallback()) { | ||
| hudOverlayFallbackExpanded = false; | ||
| applyHudOverlayBounds(); | ||
| hudOverlayWindow.setIgnoreMouseEvents(false); |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Force compact bounds when the Windows fallback is active.
Setting hudOverlayFallbackExpanded = false does not keep the fallback compact. getHudOverlayBounds() calls shouldExpandHudOverlayFallback(), which expands during any active recording with a visible webcam preview. The Windows fallback can therefore become a 540-DIP interactive window and block clicks outside the HUD bar.
Override expansion when recordingForcesHudFallback() is true. Add a regression test for an active Windows recording with a visible webcam preview.
Proposed fix
function getHudOverlayBounds() {
const { workArea } = getHudOverlayDisplay();
- const fallbackExpanded = shouldExpandHudOverlayFallback({
- fallbackExpanded: hudOverlayFallbackExpanded,
- recordingActive: hudOverlayRecordingActive,
- webcamPreviewVisible: hudOverlayWebcamPreviewVisible,
- });
+ const fallbackExpanded = recordingForcesHudFallback()
+ ? false
+ : shouldExpandHudOverlayFallback({
+ fallbackExpanded: hudOverlayFallbackExpanded,
+ recordingActive: hudOverlayRecordingActive,
+ webcamPreviewVisible: hudOverlayWebcamPreviewVisible,
+ });Also applies to: 669-677
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@electron/windows.ts` around lines 314 - 317, Update getHudOverlayBounds() or
its shouldExpandHudOverlayFallback() decision so recordingForcesHudFallback()
always forces compact bounds, regardless of active recording or visible webcam
preview. Preserve normal expansion behavior when the Windows fallback is not
forced, and add a regression test covering an active Windows recording with a
visible webcam preview.
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
While recording, the HUD overlay swaps its full-work-area click-through window for a fixed 860×160 rectangle (860×540 when the webcam preview is up) anchored bottom-centre of the work area, and enables mouse events on the whole window (
setIgnoreMouseEvents(false)).The window is transparent but still a native window, so its empty margins around the bar swallow every click aimed at the app being recorded. Reported symptom: a Save button near the bottom of the screen stops responding as soon as recording starts.
Moving the HUD does not help, for two independent reasons:
useHudBarDrag, which only translates DOM content inside the HUD window — the window, and therefore the dead rectangle, never moves.LaunchWindow.tsxthepointer-events-autobox was the parent of the transformed wrapper. CSS transforms do not move layout boxes, so that box stayed at the bar's original bottom-centre position, kept matching the.pointer-events-autohover check, and kept eating clicks there.Fix
1. Scope the compact recording fallback to Windows (
recordingForcesHudOverlayFallback, new pure helper inhudOverlayBounds.ts).The fallback earns its keep on Windows only: focus changes there silently corrupt the
WS_EX_TRANSPARENTflag behindsetIgnoreMouseEventsforwarding — the reason for the surrounding win32-gated reassert machinery — which would leave the stop button unclickable mid-recording. macOS has no such failure mode, and its renderer is already written for the full-work-area model (JS content-drag; the webcam-preview drag clamp usesscreen.width, which was silently clipped to the 860 px window before).setHudOverlayRecordingActive()now distinguishes three transitions instead of forcing!recording:That last one matters: forcing the now-fullscreen window interactive at recording start would block clicks everywhere until the first mouseleave, and forcing it click-through would drop a click already aimed at the bar.
2. Move the interactive box onto the transformed wrapper so it travels with the bar.
Behaviour by platform
setHudOverlayFallbackExpanded, which Linux skips.Testing
npm test— 1000 passed, including 4 new cases forrecordingForcesHudOverlayFallback.tsc --noEmitandbiome checkclean on the changed files.🤖 Generated with Claude Code
Summary by CodeRabbit