Repository navigation
Fix window size - #220
Merged
Merged
Fix window size#220
Conversation
SwiftUI autosaves a WindowGroup's frame under a key built from the root view's type name, modifier chain included. CrashReportSheetModifier was file-private, and a private type's context prints as "(unknown context at $addr)" where the address is the load address, which ASLR changes every launch. So each run saved its frame under a fresh key and none found the previous one. Making the type internal gives it a stable name. The default height also sat below the minimum since 8c083f5 raised the floor to 680, so a first launch was clamped rather than opening at the size asked for. 720 keeps the two in agreement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every -uiTesting fallthrough lived between init and body, so the composition root read as half test plumbing. They now sit in an extension under Homebrew/UITesting alongside the launch configuration they consume. Bodies are unchanged; the members drop private because a cross-file extension cannot reach it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MikeMcQuaid
approved these changes
Sep 17, 2026
Resize, quit with Cmd-Q, relaunch, and expect the same size back. It fails against the private modifier and passes with the fix. The runner is sandboxed, so it cannot clear the app's defaults to get a predictable starting window. A new BREW_UITEST_RESET_WINDOW_STATE launch environment key asks the app to do it: both the NSWindow Frame and NSSplitView Subview Frames keys go, because a new window with no saved frame is sized to fit the split view's restored columns. The drag lives in an XCUIElement extension. A click exactly on the edge starts no resize; a few points inside the corner does. The window is shrunk rather than grown: a default-size window can always shrink towards the minimum, whereas growing needs screen room the 1024x768 CI display does not have. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
graeme
force-pushed
the
fix-window-size
branch
from
September 17, 2026 09:58
b04751f to
f16f48e
Compare
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
The main window stopped reopening at the size it was last quit at; every launch came up at the default size.
SwiftUI autosaves a WindowGroup's frame under a UserDefaults key built from the root view's type name, modifier chain included. The crash report sheet added a file-private modifier to that chain, and Swift prints a file-private type's context as "(unknown context at $addr)". That address is the load address, which ASLR changes every launch, so each run saved its frame under a new key and never found the previous one. My defaults domain held 423 orphaned frame keys.
Making CrashReportSheetModifier internal gives it a stable name. The default window height also sat below the minimum since the floor moved to 680, so a first launch was clamped; it is now 720.
The -uiTesting seams inside BrewApp have moved to an extension under Homebrew/UITesting so the composition root reads as one thing. That commit is a pure move.
The new UI test resizes the window, quits with Cmd-Q, relaunches and expects the same size back. The runner is sandboxed and cannot clear the app's defaults, so a BREW_UITEST_RESET_WINDOW_STATE launch key asks the app to forget the NSWindow Frame and NSSplitView Subview Frames keys before it opens a window. Running the test resets the developer's own saved frame once.
Validation
macOS 26.5, Apple silicon, Xcode 26.5 (17F42), Swift 6.3.2.
scripts/test: 1094 package tests and 19 BrewUILint tests pass.
SwiftFormat, SwiftLint and BrewUILint ran through the pre-commit hook on all three commits.
scripts/test-ui, partial: WindowFrameUITests, LaunchSmokeUITests and the self-upgrade relaunch test pass. WindowFrameUITests fails with "Width was not restored" when the modifier is flipped back to private. The full UI suite was not run.
Manual: two launches of the built app wrote a single NSWindow Frame key with no "(unknown context)" segment, and a seeded 1240x900 frame survived a launch and quit.
Keyboard, VoiceOver and appearance were not checked, as nothing visible changed.
I followed the conventions and workflow, checked for duplicate PRs and kept this change focused.
I added regression coverage for bug fixes or explained why automated coverage is impractical, and reported the relevant validation above.
Screenshots
Not applicable. The only visible effect is the window reopening at its previous size; nothing in the window changes.
AI assistance
Claude Code (Claude Opus 5) found the root cause by inspecting the app's defaults domain, proposed the fix, wrote the UI test and its harness seam, and drafted this description. Claude ran the checks above; I reviewed the diff and will verify the UI test on my machine before merge.
馃 Generated with Claude Code
Fixes #174