Skip to content

Fix window width not applied correctly when resizing across displays with dock on right#1771

Closed
DinoStray wants to merge 1 commit into
rxhanson:mainfrom
DinoStray:fix/window-resize-across-displays-with-dock-on-right
Closed

Fix window width not applied correctly when resizing across displays with dock on right#1771
DinoStray wants to merge 1 commit into
rxhanson:mainfrom
DinoStray:fix/window-resize-across-displays-with-dock-on-right

Conversation

@DinoStray

Copy link
Copy Markdown

Problem

When the macOS dock is positioned on the right side, moving a window from a smaller display to a larger display using window management shortcuts (e.g., right half) could result in the target width not being applied. The window would only cover a portion of the intended half-screen area.

The issue was reproducible with "repeated command" modes when windows crossed display boundaries — the window would end up narrower than expected on the destination display.

Root Cause

macOS enforces a constraint that prevents windows from extending beyond the main screen's frame.maxX via the Accessibility API. When targeting a right-half position on a large external display (e.g., an ultrawide monitor positioned to the right of a built-in Retina display), the calculated frame's maxX could exceed the main screen's frame.maxX. The Accessibility API would silently reject or clamp the size change, leaving the window at a width that fits within the main display's bounds (e.g., 744px instead of the intended 1720px).

Changes

1. AccessibilityElement.setFrame — safe-resize strategy

When the target frame's maxX exceeds the main screen's maxX, the method now uses an alternative sequence: move to a safe X position first where the size constraint is not triggered, resize to the target dimensions, then move to the final position. This works around the macOS constraint while preserving the existing size-position-size approach for all other cases.

2. WindowManager.execute — width-aware retry logic

The cross-display retry logic previously only checked for height mismatches when deciding whether to re-apply the window frame. It now also checks for width mismatches, ensuring both dimensions are correctly applied when moving windows between displays.

Testing

Tested on macOS 26 with a dual-display setup:

  • Built-in Retina display (1512×982)
  • LG Ultrawide external display (3440×1440) positioned to the right, with the macOS dock on the right side

Reproduction steps:

  1. Place dock on the right side of the screen
  2. Open a window on the built-in display
  3. Press right-half shortcut → window correctly fills right half of built-in display ✓
  4. Move cursor to external display
  5. Press right-half shortcut → window correctly fills right half of external display ✓
  6. Toggle left-half / right-half on both displays and verify consistent behavior ✓

🤖 Generated with Claude Code

…with dock on right

When the macOS dock is positioned on the right side of the main display,
moving a window from a smaller display to a larger display could result
in the target width not being applied. The window would only cover a
portion of the intended half-screen area.

This happened because macOS enforces a constraint preventing windows from
extending beyond the main screen's frame.maxX. When the target frame's
right edge would exceed this boundary, the Accessibility API would reject
the size change.

Two fixes applied:

1. AccessibilityElement.setFrame: When the target frame's maxX exceeds
   the main screen's maxX, use a safe-resize strategy — first move the
   window to a position where it fits within the constraint, resize it
   to the target size, then move it to the final position. This works
   around the macOS constraint while maintaining the existing
   size-position-size approach for all other cases.

2. WindowManager.execute: In the cross-display retry logic, also check
   for width mismatches (not just height) when deciding whether to retry
   the window placement. This ensures width discrepancies are also
   corrected when moving windows between displays.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@rxhanson

rxhanson commented Jun 4, 2026

Copy link
Copy Markdown
Owner

Thanks for contributing!

I think there might still be something to iron out prior to merging, as I'm not able to reproduce the issue being fixed here. Would you mind providing a little more details on what might need to be done to reproduce it, or a video of it not working correctly so I can figure it out? I've tried with MBP display set as main, and external display set as main, going in both directions (even though the problem description is from smaller display to larger), and I wasn't able to see the issue.

It's not entirely clear to me why the setFrame adjustment is based on the main screen only since a window could be placed on a display other than the main screen, so I expect that when I can reproduce the issue then I'll have a clear picture.

@rxhanson

Copy link
Copy Markdown
Owner

I'm still interested in this if you're looking to move it forward and want to provide more details on how I can reproduce it and validate that the fix is good. Thanks!

@rxhanson

Copy link
Copy Markdown
Owner

I'll close this one out for now since I haven't heard back, but I'm definitely still interested if this does indeed solve an issue that you were experiencing.

@rxhanson rxhanson closed this Jun 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants