fix(connection-form): bring the New Connection window to the front on the first open

[datlechin]

The problem

From the Welcome window, Import from URL opens a sheet. Pasting a connection URL and clicking Import opened the New Connection window behind the Welcome window on the first attempt, then in front on later attempts.

Root cause

Apple documents openWindow ordering a window to the front only when it reuses one. From OpenWindowAction:

If the interface already has a window from the group that's presenting the specified value, the system brings the window to the front. Otherwise, the system creates a new window and passes a binding to the specified value.

There is no ordering or key guarantee on the create path. Meanwhile AppKit hands key status from a dismissing sheet back to its sheetParent asynchronously, as the dismissal animation ends.

ImportFromURLSheet.submit() called openWindow and then dismiss(), so both were in flight at once. On the first attempt SwiftUI had to build the window from scratch, so it landed after the Welcome window was raised again. On later attempts the window already existed, so openWindow took the documented reuse path, which is a cheap order-front that won the race.

Nothing corrected for this. Every AppKit-created window in the app pairs creation with an explicit raise (TabRouter does it at 13 call sites, WindowManager.openTab), but the SwiftUI openWindow scenes had no such step.

Two further problems came from the same cause:

1. The type chooser sheet and the project folder scan sheet had the identical race, not just Import from URL.
2. Every "new connection" caller passed the window value nil, so they all shared one window identity. With a New Connection window already open, a repeat import only re-fronted it. ConnectionFormView's guard coordinator == nil then blocked re-initialisation, so the staged URL was never consumed and the pasted URL was silently discarded.

The fix

Window identity now encodes intent. ConnectionFormRequest replaces UUID? as the WindowGroup value:

• .edit(connectionId:) is stable, so re-opening the same connection reuses its window and gets Apple's documented order-front. This also stops two editors opening on one connection.
• .create(draftId:) carries a fresh id per invocation, so every new connection gets its own window. This follows EditorTabPayload, which already uses a per-window id for the same reason, and matches the macOS convention that New always makes a new one.

The sheets now sequence instead of racing. The button action stages the draft and dismisses; the window opens from .sheet(onDismiss:). That is the documented hook, and it is what the HIG prescribes: "Let people dismiss a modal view before presenting another one." Applied to all three creation sheets.

The window raises itself. WindowSelfRaiser calls makeKeyAndOrderFront(nil) once from viewDidMoveToWindow. This needs no polling and no window-identifier matching, and it also covers the paths that have no sheet to sequence against (duplicating a connection, File > New Connection). It is a separate type rather than a flag on WindowChromeConfigurator, because that type's updateNSView runs on every re-render and a raise must never fire on that cadence.

Secrets stay out of the window value. WindowGroup(for:) values are Codable and SwiftUI persists them for state restoration, and ParsedConnectionURL holds password and sshPassword. The value carries only identity; the parsed URL travels in ConnectionFormDraftStore, an in-memory store keyed by draft id that clears an entry the moment it is read. This replaces the PendingNewConnectionImport and PendingNewConnectionType singletons, whose single global slot was what allowed the URL to be dropped.

Also removes WelcomeViewModel.focusConnectionFormWindow(), which scanned NSApp.windows in the same call stack as openWindow and so was almost always a no-op, along with the now-unused AppLaunchCoordinator.isConnectionFormWindow.

Rejected on the evidence: NSApp.activate(ignoringOtherApps:) (soft-deprecated, and the app is already active so activation was never the problem), orderFrontRegardless() (Apple: "You should rarely need to invoke this method", and it defeats the macOS 13.3+ protection against stealing focus from another app), and any fixed delay.

Tests

22 tests, all passing. The ones that would have caught these bugs:

• testChoosingATypeStagesTheDraftWithoutOpeningTheWindow asserts the window does not open while the sheet is still up. This is the race itself, at the unit level.
• testEachStagedDraftOpensItsOwnWindow asserts two creations produce different window values. This is the shared-nil identity bug.
• testTheStagedURLReachesTheWindowOpenedForIt and twoStagedDraftsDoNotContaminateEachOther cover the silently dropped URL.
• ConnectionFormRequestTests covers equality, the accessors, and the Codable round trip the WindowGroup value depends on.

Window z-order and key status are not asserted. There is no window server in the test host and no precedent for it in this codebase, so that part is manual: on a fresh launch, first try, Import from URL from the Welcome window.

Heads up on the suite as a whole: it runs 9117 passed / 70 failed locally, and those 70 are pre-existing. I confirmed by running the failing suites (OracleCellFormattingTests, EtcdPrefixRangeEndTests, MCPPairingServiceTests, DatabaseConnectionExternalAccessTests) on the unmodified base commit c790e763 in a clean worktree, where exactly the same tests fail. Unrelated to this branch.

Not included

No docs/ change. This restores documented behaviour rather than changing what the feature does.

Worth a separate discussion: no mature native client (TablePlus, Postico 2, Sequel Ace, DataGrip, Beekeeper, Compass, DBeaver) opens a separate top-level window for this, they keep the flow in one window. That redesign is out of scope here, and it is blocked anyway by the form needing 560pt of height against a fixed, non-resizable 480pt Welcome window.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.