Fix Settings/Rules panes going stale after cross-window tab drag (APP-5311) - #14950

Description

Fixes APP-5311: Settings (and the AI-facts "Rules" pane) could not be reopened after their tab was dragged into a new window and that window was closed.

Root cause. A cross-window tab drag intentionally suppresses the normal PaneContent::detach/attach hooks on the source window (Workspace::prepare_for_transferred_tab_attach). This left three related bugs, all rooted in per-window singleton state (SettingsPaneManager, AIFactManager) and per-view event subscriptions not knowing the pane had moved:

• A. SettingsPaneManager/AIFactManager kept a locator on the source window pointing at a pane group that no longer lived there. Reopening Settings/Rules from that window silently no-op'd forever, because focus_pane resolves the stale locator to nothing and returns early.
• B. A transferred SettingsView's SettingsViewEvent subscription is registered once, in Workspace::build_settings_views, against whichever workspace created it. It does not follow the view when the view transfers to another window. So an action taken from a Settings pane now hosted in window B (e.g. clicking "Rules") executed in the stale window A instead of window B.
• C. The AIFactManager equivalent of A, compounded by B's routing bug (clicking "Rules" from a transferred Settings pane routed to the wrong window's open_ai_fact_collection_pane, which then hit its own stale/absent locator and silently did nothing).

Fix (initial):

• PaneGroup::on_window_transferred re-keys the SettingsPaneManager/AIFactManager locator from the source window to the destination window whenever a transferred pane group contains a SettingsPane/AIFactPane, and re-homes the SettingsView/AIFactView event subscription from the source workspace to the destination workspace.
• Workspace::open_settings_pane and open_ai_fact_collection_pane are defensive: if the registered locator does not resolve to a live pane in the current window, they clear it and open a fresh tab/pane instead of silently doing nothing.

Fix (after adversarial review — this revision):

• Re-entrancy panic. The subscription rehoming above ran synchronously inside on_window_transferred, but in a real drag that runs while the source Workspace is already mid-update (handle_action(DropTab) → perform_handoff → CrossWindowTabDrag::execute_handoff_single_tab_to_other → AppContext::transfer_view_tree_to_window). Calling ViewHandle::update on that same, currently-removed-from-its-window view panicked with "Circular view update". It's now dispatched as a self-targeted, deferred PaneGroupAction (not run synchronously, and not routed through the ancestor chain, which isn't reliably populated for a just-transferred view until the next render pass).
• Wrong view updated. open_settings_pane/open_ai_fact_collection_pane were updating this window's own native (possibly unrendered) self.settings_pane/self.ai_fact_view instead of the concrete SettingsPane/AIFactPane the locator actually points at. Page/search navigation and OpenAIFactCollection routing now resolve and update the pane that's actually hosting the transferred view.
• Narrower visibility. SettingsPane::settings_view is now pub(crate) instead of pub.
• One-pane-per-window invariant. Per product decision, Warp intentionally allows at most one Settings pane and one Rules pane per window. SettingsPaneManager/AIFactManager gained register_transferred_pane, which detects a collision with an existing pane in the destination window instead of silently overwriting the locator (which used to leave the pre-existing pane live but untracked). On collision, the transferred pane is discarded — closing its whole tab if it was the tab's only content, otherwise just the pane — and the pre-existing pane is kept and focused, via a second self-targeted deferred WorkspaceAction (DiscardDuplicateTransferredPane) so the discard never touches the transferred pane group while it's still mid-update.

Linked Issue

• Linear: APP-5311 — https://linear.app/warpdotdev/issue/APP-5311/settings-cannot-reopen-after-detaching-settings-tab-to-a-new-window
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

Regression tests in app/src/workspace/view_tests.rs, each exercising the production cross-window-transfer primitives (AppContext::transfer_view_tree_to_window / Workspace::perform_handoff + insert_transferred_tab_at_index + remove_tab_without_undo/remove_tab) rather than mocking them away:

• test_settings_pane_reopens_after_cross_window_transfer_and_close (symptom A)
• test_settings_pane_actions_execute_in_hosting_window_after_cross_window_transfer (symptom B)
• test_ai_fact_pane_reopens_after_cross_window_transfer_and_close (symptom C)
• test_settings_pane_transfer_via_real_handoff_path_does_not_panic — drives the real single-tab Workspace::perform_handoff entry point (not a bare top-level transfer call) so the transfer runs nested inside the source workspace's own update, reproducing the call stack that used to panic.
• test_settings_pane_page_navigation_after_transfer_updates_transferred_view — proves page navigation updates the transferred pane's own view, not this window's unused native one.
• test_settings_pane_transfer_into_window_with_existing_pane_discards_duplicate / test_ai_fact_pane_transfer_into_window_with_existing_pane_discards_duplicate — collision reconciliation for both pane kinds: no duplicate survives, the pre-existing pane stays reachable, and closing it still lets a fresh one open.

I verified the original three tests fail without the initial on_window_transferred fix (by temporarily reverting just that change) and pass with it restored. The new tests were written against the reviewed (broken) intermediate states first and confirmed to fail there before the final fix made them pass.

Ran:

• cargo nextest run -p warp for the touched modules (workspace::, pane_group::, plus settings/ai_fact/cross_window filters): 517 tests, all passing.

• ./script/format — clean.

• cargo clippy -p warp --all-targets -- -D warnings — clean.

• I have manually tested my changes locally with ./script/run (see note below)

Manual/GUI verification note: I attempted to verify the fix end-to-end with a live build (cargo build --bin warp succeeded, then drove the running app via computer-use) but the sandbox's WARP_API_KEY resolves to an agent identity rather than a real user account, so the app never leaves the logged-out onboarding screen (backend rejects it with "Expected a user account") and I could not reach the terminal UI to exercise the Settings tab. I'm reporting this limitation rather than claiming GUI verification that didn't happen — the recording/screenshot below document the auth blocker, not the fix in action. The fix is otherwise fully covered by the fail-before/pass-after regression tests above, including a dedicated test for the exact re-entrancy call stack that previously panicked.

Screenshots / Videos

Computer-use video recordings

Warp Settings detach and reopen flow: Attempted run, blocked at onboarding due to the sandbox API key not being a user-account credential (see note above).

Computer-use screenshots

Warp stuck on the logged-out "Welcome to Warp" onboarding screen — the auth blocker described above, not the fixed flow.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Conversation: https://staging.warp.dev/conversation/69399d8d-001f-4932-a315-3ccf9430e4b9
Run: https://oz.staging.warp.dev/runs/019ff1d9-0c2c-719e-92b5-86326ccefe3a

This PR was generated with Oz.