fix(welcome): keep the welcome toolbar at Icon Only - #3146
Merged
datlechin merged 4 commits intoSep 28, 2026
Merged
Conversation
Contributor
Author
|
@datlechin Not sure failing test are relevant with this changes |
6 tasks
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
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.
Summary
The welcome window's toolbar is built for three icon buttons and a search field in a fixed 900x600 window, but on macOS 15 and later a right-click on it offered Icon and Text and Text Only. Choosing Icon and Text put titles under New Connection and New Group and AppKit's own "Search" caption under the search field, and the toolbar grew taller.
The toolbar now stays at Icon Only and offers no display-mode choice, the same way Contacts, Calendar, Music and App Store handle their fixed toolbars.
Root cause
WelcomeWindowControllerdid declare a fixed toolbar: anNSToolbarwithdisplayMode = .iconOnlyandallowsUserCustomization = false. That declaration never reached the toolbar on screen, for two reasons:NSHostingControllerwithsceneBridgingOptions = [.toolbars]. SettingcontentViewControllermakes SwiftUI replacewindow.toolbarwith its own toolbar. That toolbar has an empty identifier, no autosave, andallowsDisplayModeCustomization == true. Measured on macOS 27.allowsDisplayModeCustomization(macOS 15) is separate fromallowsUserCustomizationand defaults totrue. So even the original toolbar never opted out of the display-mode menu.Fix
WelcomeWindowController.makeWelcomeWindow()builds the window. It is anNSWindowsubclass whosetoolbardidSetfixes whichever toolbar is installed at Icon Only: the original toolbar on macOS 13, and SwiftUI's replacement on 14 and later, whenever it arrives. Measured: the setter runs for both, and the lock survives a SwiftUI state change, a root view swap and re-showing the window.NSToolbar.hsaysallowsDisplayModeCustomization"defaults to YES for apps linked on macOS 15.0 and above". Before that, AppKit offers the display-mode menu only on a toolbar withallowsUserCustomizationset, and the toolbar SwiftUI installs has it off. Measured by stamping a probe binary as linked against the macOS 14 SDK (vtool -set-build-version macos 14.0 14.0) and running it on macOS 27. The non-customizable toolbar, both AppKit-owned and SwiftUI-bridged, showed an empty context menu. The same binary linked against SDK 27 offered Icon and Text, Icon Only and Text Only. This is AppKit's own compatibility path on macOS 27, not a run on a macOS 14 machine.This replaces the earlier version of this PR, which added View Options > Toolbar > Icon and Text / Icon Only. The review found that setting was never saved, made the system menu a control that did nothing on macOS 14, and needed a second observable object passed through four constructors. Locking the toolbar fixes the same bug with none of that.
Before / After
Before, in Icon and Text (titles under the icons and a Search caption):
After, the only mode the toolbar has, Icon Only:
Right-clicking an empty part of the toolbar now shows no display-mode items. I did not capture a new screenshot: another session was running a load test on this machine, and a second TablePro process would have disturbed it.
Testing
WelcomeToolbarTests(3 cases) runs against the realmakeWelcomeWindow(). It covers the window's own toolbar, a toolbar assigned later, and the toolbar SwiftUI installs for a scene-bridged hosting controller with a.searchablefield. 3 of 3 pass.swiftlint lint --stricton both changed Swift files: 0 violations.NSToolbarViewbackground. No existing UI test does that, and XCUITest has no deterministic way to hit an empty toolbar spot instead of the search field or a button.