🐞 Maximize across displays may apply stale vertical constraints on first attempt

[joaquinveraro]

Bug Description

When Use screen with cursor is enabled, applying Maximize to a window that is currently on one display while the cursor is on another display may require two attempts.

The first attempt moves the window to the target display but leaves it only partially maximized. A second Maximize immediately afterward works correctly.

This appears to be specific to cross-display resizes. If any other Loop action is performed after moving the window to the target display, then Maximize works correctly on the next attempt.

Steps To Reproduce

1. Enable Use screen with cursor.
2. Disable window resize animations.
3. Put a resizable window on display A.
4. Move the cursor to display B.
5. Open Loop and choose Maximize once.
6. Observe that the window moves to display B but is not fully maximized vertically.
7. Choose Maximize again.
8. Observe that the second attempt correctly fills display B.

Expected Behavior

A single Maximize action should move the window to the display under the cursor and apply the final maximized frame in that same operation.

Actual Behavior

The first cross-display Maximize moves the window to the new display but can leave it vertically constrained. A second Maximize is required.

Reproduction Data

Loop version: 🧪 1.4.3 (1763)

Relevant settings:

useScreenWithCursor = 1
useSystemWindowManagerWhenAvailable = 0
animateWindowResizes = 0
moveCursorWithWindow = 0

For one reproduction with ChatGPT:

Loop computed and requested this target frame:

(-1074.0, -370.0, 1068.0, 1878.0)

Loop log:

[ResizeContext] Computed target frame - raw: (-1074.0, -370.0, 1068.0, 1878.0), ... for action: WindowAction(direction: Maximize, name: Maximizar)
[WindowEngine] Resizing Window(id: 60994, app: 'ChatGPT', title: 'ChatGPT) to (-1074.0, -370.0, 1068.0, 1878.0)

Immediately after the first failed resize, Accessibility reported the actual window frame as:

x=-1074 y=-156 w=1068 h=1450

So the X position and width were correct, but the vertical geometry remained constrained. This suggests the target frame calculation is correct and the issue occurs while applying the frame during the display transition.

Possible Cause

In the current code path, cross-display resizes use:

await window.setFrame(targetFrame, sizeFirst: willChangeScreens, resolvedProperties: resolvedProperties)

and Window.setFrame(..., sizeFirst: true) applies size before position, then size again.

My suspicion is that the first size assignment is constrained by the old display, and the immediate second size assignment may occur before macOS has fully updated the window's display membership.

A potentially more robust approach may be to move the window to the destination display, wait until ScreenUtility.screenContaining(window) resolves to the destination screen, and then apply the final target frame.

Additional Context

This is reproducible specifically when moving between displays and maximizing in the same action. If the window is already on the destination display, Maximize works on the first attempt.

I can provide more logs or test a patch if useful.

[joaquinveraro]

One additional UX/feature request related to this workflow: it would be great if Loop could optionally assign an action to holding the trigger key without moving the mouse.

Example desired behavior:

• Hold the Loop trigger key (in my case Control).
• If the pointer moves, Loop behaves normally and the radial menu/action selection works as it does today.
• If the pointer does not move for a configurable short delay, Loop runs a user-selected action immediately (for me, Maximize).
• Releasing the key before the delay would cancel it.

Even more generally, it could be configurable so a modifier such as Option/Control held with no pointer movement invokes a chosen action. This would make common actions like Maximize accessible without having to deliberately nudge the cursor into the center region every time, while preserving the existing radial-menu behavior when the mouse is moved.

A configurable delay and configurable action would make this useful beyond Maximize as well.

[mrkai77]

Thanks for reporting this, @joaquinveraro! Just to confirm, is this a new issue that started within the past few days, or has it always been happening? Also, which version of macOS are you currently using? Both of those details would help us narrow down the possible causes.

As for the additional feature request, we try to keep each GitHub issue focused on a single feature or bug so it’s easier for us to track everything. It would be great if you could open a separate issue for that!

[joaquinveraro]

Thanks! This is not a new regression for me — I have been seeing it consistently for as long as I’ve used this setup with a vertical external monitor.

I’m currently on macOS Tahoe 26.6.2 on a 13-inch MacBook Air (M4, 2025).

The important reproduction detail is that the problem only happens when Maximize is the first Loop action used while moving the window to another display:

1. The window starts on display A.
2. I move the pointer to display B (my vertical monitor), with Use screen with cursor enabled.
3. I invoke Maximize directly.
4. Loop moves the window to display B, but the first result is vertically constrained / only partially maximized.
5. Invoking Maximize a second time fixes it.

However, if I first perform any other Loop action on display B — for example moving the window to the bottom of that display — and then invoke Maximize, it works correctly on the first Maximize attempt.

So it seems specifically related to changing displays and applying Maximize in the same operation, rather than Maximize itself.