apply Maximize after a cross-display move

[mvanhorn]

Description

The resize keeps the source display bounds and, when the screen will change and the target width or height exceeds those bounds by more than 2 points, moves the window to the target origin before sizing. It then applies the full frame with sizeFirst false, waiting 16 milliseconds before each attempt, and stops when the read-back is within the 10-point approximatelyEqual tolerance or after 20 applies. Resizes that stay on one screen, have no source display, or fit inside the source bounds still size first, and retry once if the read-back does not match. shouldMoveBeforeSizing and shouldReapplyFrame hold those decisions, and CrossDisplayResizeTests exercises them with the reported 1470 by 956 source, the 1068 by 1878 target, and the clamped 1068 by 1450 read-back.

With Use screen with cursor enabled, the first Maximize that also moves a window onto another display can leave it only partly maximized. The window takes the requested x and width on the destination, but the vertical edges stay short of the target frame, so a second Maximize is required to fill that display. On a non-animated cross-display resize, setFrame is called with sizeFirst, so the window is sized while it still belongs to the source display. WindowServer clamps a target larger than that display, and the second size inside setFrame runs before display membership updates, leaving the clamped frame in place. A maximize onto a taller display exceeds the source height and hits that clamp.

Fixes #1148

How has this been tested?

• Test A
• Test B

The test command did not run a suite for the touched files.

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.

Nothing to add for this change.

AI disclosure

AI was used for assistance.

• Tools: Cursor.

[mrkai77]

Hey, thanks for looking into this! Unfortunately, this isn't something we can merge as-is.

Our AI usage policy asks that AI-assisted PRs are tested in the environments they target, and that you don't submit code for configurations you can't personally run. This bug only happens when moving a window between two displays, and the testing section here is still the template's placeholders, with a note that the tests weren't run. That's something we'd need to see verified before reviewing it in depth.

I also don't think this fixes the underlying problem. It retries setFrame up to 20 times until the frame sticks, instead of finding out when the window actually belongs to the new display. The explanation also doesn't quite match the data in #1148: the window ended up 1450 pt tall, which is larger than the 956 pt source display the tests assume, so it doesn't look like the window was clamped to the source display. Retrying like this would also cause visible jitter for windows with size constraints, since those never reach the target frame.

For future PRs, please make sure to fill out the PR template completely, including the checklist and how it's been tested!