[jvanderen1]

Description

Snapping a window to a smaller frame on the same screen moved it first and resized it second. A window that is still at its old width, slid onto a third, hangs off the display. Finder and TextEdit accept the following shrink. iTerm2 does not.

On macOS 27.0.1, dragging iTerm2 onto a third left the window wider than the screen. Horizontal shrinking then stopped, while growing still worked, so the window could only ratchet larger. Resize-smoothly was already on, so this was not iTerm2's character-grid snap. Finder and TextEdit showed the same grow-then-shrink, then landed on the third.

WindowEngine.resizeWindow passed sizeFirst: true only when the window changed screens. Window.setFrame otherwise sets the origin, then the size. If the frame missed, the retry called setFrame again with that default and moved first a second time. That off-screen frame is what AppKit latches. iTerm2 commit 368018c30 logs the symptom: a healthy terminal window has minSize and contentMinSize of {0, 0}, and AppKit clamps later resizes to the window's own frame before windowWillResize:toSize:. Shrinking is refused. Growing still works.

setFrame already knows how to size first: set the size, then the origin, then the size again. This change passes sizeFirst when the target is narrower or shorter than the window's current size, including on the retry, and still passes it when the window changes screens. A same-screen grow stays position-first, so the window expands from the edge it was aimed at. The animated shrink path already calls setSize before setPosition, so it is unchanged.

Stash placement and restoring a dragged window's initial size use the same check when they apply a smaller frame.

This stops Loop from creating the bad frame. It does not clear a minimum size that AppKit has already latched on an iTerm2 window.

How has this been tested?

macOS 27.0.1 (26A434). Window-resize animation off.

• Snap iTerm2, Finder, and TextEdit to a left, center, or right third on the same screen. The window shrinks, then moves, and does not stay wider than the display.
• WindowEngineSizeFirstTests: a narrower or shorter target sizes first, a same-screen grow stays position-first, and a screen change still sizes first.

Screenshots (if appropriate)

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in this PR.

Please describe to which degree, if any, an LLM was used in creating this pull request.

Cursor traced the resize order from the report above and drafted the change. I reviewed the diff and verified the same-screen third snaps locally.

Made with Cursor

[jvanderen1]

@mrkai77 Hello! I was wondering if you could take a look at this? It should help improve resizing for all apps.