Skip to content

fix(highlight): screen highlight clipping on macOS#237

Open
Andrii-Vovk wants to merge 1 commit intowebadderallorg:mainfrom
Andrii-Vovk:fix/macos-screen-highlight-bounds
Open

fix(highlight): screen highlight clipping on macOS#237
Andrii-Vovk wants to merge 1 commit intowebadderallorg:mainfrom
Andrii-Vovk:fix/macos-screen-highlight-bounds

Conversation

@Andrii-Vovk
Copy link
Copy Markdown

@Andrii-Vovk Andrii-Vovk commented Apr 14, 2026

Summary

On macOS, the screen highlight overlay's right and bottom edges were running off-screen. macOS clamps window positions below the menu bar, so the outward padding only appeared on the left/top while the right/bottom extended beyond the visible area.

Related to this issue - this is why i thought there wasn't any highlighting

Changes

  • Use display workArea instead of full bounds for screen highlights on macOS, keeping the overlay within the visible screen area
  • Keep the border and glow flush within the overlay window (no outward padding for screen sources on macOS)
  • Scoped to macOS only — Windows and Linux behavior is unchanged

Test plan

Unfortunately i don't have a windows machine on hand to check this myself

  • Select a screen source and verify the highlight border is visible on all four edges
  • Verify window highlights still show the padded glow on all sides
  • Test on a multi-monitor setup to confirm highlight appears on the correct display
  • Verify no regressions on Windows/Linux screen highlights

Summary by CodeRabbit

  • Bug Fixes
    • Improved screen capture highlight positioning and display work area detection on macOS
    • Enhanced highlight overlay visual styling on macOS screens with updated borders and glow effects

   On macOS, the screen highlight overlay's right and bottom edges were
   running off-screen. macOS clamps window positions below the menu bar,
   so the outward padding only appeared on the left/top while the
   right/bottom extended beyond the visible area.

   Use display workArea instead of full bounds for screen highlights on
   macOS, and keep the border/glow within the overlay window.
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 14, 2026

Warning

.coderabbit.yaml has a parsing error

The CodeRabbit configuration file in this repository has a parsing error and default settings were used instead. Please fix the error(s) in the configuration file. You can initialize chat with CodeRabbit to get help with the configuration file.

💥 Parsing errors (1)
Validation error: Invalid regex pattern for base branch. Received: "*" at "reviews.auto_review.base_branches[0]"
⚙️ Configuration instructions
  • Please see the configuration documentation for more information.
  • You can also validate your configuration using the online YAML validator.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
📝 Walkthrough

Walkthrough

A handler function computes display work areas for macOS screen sources and adjusts highlight styling by using workArea instead of bounds, while conditionally applying platform-specific visual parameters like border radius and glow effects.

Changes

Cohort / File(s) Summary
macOS Display Highlight Handler
electron/ipc/handlers.ts
Added getDisplayWorkAreaForSource() to compute display bounds using workArea. Updated show-source-highlight handler to use this function for macOS screen sources. Adjusted highlight padding from 6 to 0 and introduced conditional styling variables for borderRadius, glowInset, glowRadius, and glowPad based on platform.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🖥️ A highlight dance on Apple's screen,
Work areas now more keen,
Borders sharp and glows subdued,
macOS styling renewed! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: fixing screen highlight clipping on macOS, which aligns with the primary objective of the pull request.
Description check ✅ Passed The PR description comprehensively covers the issue, changes, and testing approach with clear sections matching template requirements.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
electron/ipc/handlers.ts (1)

2348-2354: Consider extracting a platform-neutral display resolver.

This works, but getDisplayWorkAreaForSource() now depends on resolveWindowsCaptureDisplay() for a macOS path. The logic is generic, so the Windows-specific name is starting to obscure what this helper really does. A neutral resolver name/module would make future platform-specific highlight work easier to follow.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@electron/ipc/handlers.ts` around lines 2348 - 2354, The helper
getDisplayWorkAreaForSource is calling resolveWindowsCaptureDisplay which is a
Windows-named function but contains generic selection logic; extract and rename
that logic to a platform-neutral resolver (e.g., resolveCaptureDisplay or
getCaptureDisplayForSource) in a shared module, update
getDisplayWorkAreaForSource to call the new neutral function, and keep any
Windows-specific branching inside the resolver (guarded by platform checks) so
callers no longer reference Windows-specific names like
resolveWindowsCaptureDisplay.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@electron/ipc/handlers.ts`:
- Around line 2348-2354: The helper getDisplayWorkAreaForSource is calling
resolveWindowsCaptureDisplay which is a Windows-named function but contains
generic selection logic; extract and rename that logic to a platform-neutral
resolver (e.g., resolveCaptureDisplay or getCaptureDisplayForSource) in a shared
module, update getDisplayWorkAreaForSource to call the new neutral function, and
keep any Windows-specific branching inside the resolver (guarded by platform
checks) so callers no longer reference Windows-specific names like
resolveWindowsCaptureDisplay.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 75689eaf-c853-4a55-bcf2-bdfafec3a348

📥 Commits

Reviewing files that changed from the base of the PR and between e34881f and 94ae6d3.

📒 Files selected for processing (1)
  • electron/ipc/handlers.ts

@webadderall
Copy link
Copy Markdown
Collaborator

thanks for the contribution, could you please fix merge conflicts and then it'll be good to go :)

@Andrii-Vovk
Copy link
Copy Markdown
Author

Will fix conflicts this weekend, sorry for the delay

@meiiie
Copy link
Copy Markdown
Collaborator

meiiie commented Apr 23, 2026

Quick triage pass: I don’t see any active review threads on this one at the moment either. It currently looks like a clean-review candidate that’s just blocked on the merge conflict, so a rebase onto current main would be the next useful step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants