🐞 Maximize across displays may apply stale vertical constraints on first attempt
Maintainers usually reply within 1 day
Nobody has claimed this yet.
- #1181 by @mvanhorn — closed without merging
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
Research direction
Trace the cross-display path through ResizeContext and WindowEngine, focusing on Window.setFrame(..., sizeFirst: true) and ScreenUtility.screenContaining(window). Reproduce with Use screen with cursor enabled and animations disabled, then compare the requested and Accessibility-reported frames across the first Maximize attempt. Done means one action moves the window to the cursor's display and fully maximizes it.
Written by the indexing model from the issue text.
Description
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
- Enable Use screen with cursor.
- Disable window resize animations.
- Put a resizable window on display A.
- Move the cursor to display B.
- Open Loop and choose Maximize once.
- Observe that the window moves to display B but is not fully maximized vertically.
- Choose Maximize again.
- 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.
- Dominant language
- Swift
- Stars
- 11.9k
- Forks
- 287
- Avg merge
- 17h 7m
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mrkai77/Loop
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
🐞 Crash when editing the search field in the keybind action pickerPossibly taken @NicoCorini claimed this 10 days ago. OpenBug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
mrkai77/Loop#1187 · 4 comments ·
Maintainers usually reply within 1 day
-
Bug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Bug
Difficulty 4/5 3-5 days Newbie friendliness 55/100
mrkai77/Loop#1191 · 1 reaction ·
Maintainers usually reply within 1 day
-
✨ Prioritize Custom Trackpad Gestures Over Default Radial Menu GesturesPossibly taken @mrkai77 claimed this 16 days ago. OpenFeature
Difficulty 4/5 3-5 days Newbie friendliness 25/100
mrkai77/Loop#1177 · 1 reaction ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
swiftlang/swift-markdown#299 ·
-
area: agents follow-up
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
manaflow-ai/cmux#37234 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug product / functions
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 61/100
JWhite212/SignalLadder#215 ·
Maintainers usually reply within 1 day