fix(cursor): align editable cursor overlay with window-mode recordings#44
fix(cursor): align editable cursor overlay with window-mode recordings#44marktolson wants to merge 1 commit into
Conversation
When recording a single window on macOS, the editable cursor overlay was offset from the real cursor by a significant amount on both axes, so clicks in playback landed on elements the visible cursor wasn't over. Root cause: cursor telemetry was normalized against the whole display's bounds, but a window recording's video only contains the window. The overlay was therefore placed at the cursor's position relative to the full screen instead of relative to the captured window, offset by the window's on-screen origin (and scaled by the display/window size ratio). Fix (mirrors the existing Windows cursor sampler, which already reports per-sample window bounds): - The macOS cursor helper now accepts the target windowId and, each sample, reads that window's live on-screen frame via CGWindowListCopyWindowInfo (top-left points, same space as Electron's getCursorScreenPoint) and emits it as `bounds`. Reading it per sample also keeps alignment correct if the window is moved mid-recording. - MacNativeCursorRecordingSession normalizes against the emitted window bounds when present, falling back to the display bounds otherwise, via a new pure `normalizeCursorToBounds` helper. - The source id is threaded through the factory so the session can detect window capture and pass the windowId to the helper. Adds unit tests for normalizeCursorToBounds, including a regression test showing the same physical point maps correctly to the window vs. the (previously used, misaligned) display-relative coordinates. Co-authored-by: Cursor <cursoragent@cursor.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds window-scoped cursor normalization for macOS window capture. The Swift cursor helper gains a ChangesWindow-aware macOS cursor normalization
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
this issue is already fixed on main. Commit 3ef2001 (June 23, by giulio333): fix(macos): correct cursor offset in single-window capture addresses the same root cause — cursor normalized against display bounds instead of window bounds during single-window macOS recording. PR #44 (June 29, by marktolson) is a duplicate fix for the same problem. The commit is already in main and on your current branch. The approach differs slightly (PR #44 modifies the cursor helper and factory; 3ef2001 modifies the ScreenCaptureKit helper + IPC handlers + nativeMacRecording.ts), but they address the identical bug. closed as a duplicate. |
Summary
Fixes editable-cursor overlay misalignment when recording a single window on macOS. Previously, during playback the overlay cursor was offset from the real cursor by a significant amount on both X and Y — clicks landed on elements the visible cursor wasn't over.
Root cause
Cursor telemetry was normalized against the whole display's bounds, but a window recording's video only contains the window. The overlay was therefore placed at the cursor's position relative to the full screen instead of relative to the captured window — offset by the window's on-screen origin and scaled by the display/window size ratio.
Fix
Mirrors the existing Windows cursor sampler, which already reports per-sample window
bounds:windowIdand, each sample, reads that window's live on-screen frame viaCGWindowListCopyWindowInfo(top-left points — the same coordinate space as Electron'sscreen.getCursorScreenPoint()) and emits it asbounds. Reading it per sample also keeps alignment correct if the window is moved mid-recording.MacNativeCursorRecordingSessionnormalizes against the emitted window bounds when present, falling back to display bounds otherwise, via a new purenormalizeCursorToBoundshelper.windowIdto the helper.Display (full-screen) capture is unchanged — with no
windowIdthe helper emits noboundsand the display fallback is used.Tests
normalizeCursorToBounds, including a regression test showing the same physical point maps correctly to the window vs. the previously-used (misaligned) display-relative coordinates.Verification
tsc --noEmitcleanvitest— 277 passing (incl. the new regression test)swiftc, macOS 13 target)Notes
OpenScreenMacOSCursorHelper), so anpm run build:native:macis needed to ship the updated helper.Summary by CodeRabbit
New Features
Bug Fixes