Clicking away from an in-progress pane-group rename discards the edit instead of committing it (macOS inline-rename norm)

[fbartho]

Describe the bug

When renaming a pane group in the vertical-tabs sidebar (code-side these are tab groups), the new name only takes effect on Enter. Clicking elsewhere while the rename field is open silently discards the edit. The macOS convention for inline rename (Finder, Xcode's navigator, Notes) is commit-on-blur: clicking away confirms the name; Escape is the cancel gesture.

To reproduce

1. In the vertical-tabs sidebar, double-click a pane group's header (or choose Rename from its right-click menu)
2. Type a new name
3. Click the sidebar background instead of pressing Enter
4. The name reverts to its previous value

Expected

Click-away commits the new name; Escape remains the way to cancel.

Where the behavior comes from

This looks at least partly intentional, so I'm framing it as a design decision worth revisiting rather than a plain bug:

• The rename editor itself already commits on blur: handle_tab_group_rename_editor_event maps EditorEvent::Blurred | Enter => finish_tab_group_rename (app/src/workspace/view.rs:1482-1501). That matches the rest of the app — tab rename, pane rename, conversation rename, the host-picker slug editor, and most settings fields handle Blurred | Enter the same way, and the file tree commits on blur via its View::on_blur hook ("matches VS Code").
• But the vertical-tabs panel background dispatches WorkspaceAction::CancelActiveRename on click (app/src/workspace/view/vertical_tabs.rs:1718-1720), and that action is documented as deliberate: "Cancels any active rename … without committing … Dispatched when clicking on the vtab panel background while a rename editor is open" (app/src/workspace/action.rs:189-192). Its handler cancels all three rename kinds (view.rs:23859-23863); clearing the rename state makes the editor's blur-commit early-return into a no-op (view.rs:1557-1560).

Why I think it's worth changing

• It's inconsistent with itself: click-away onto the sidebar background discards the edit, while click-away onto a focusable target outside the sidebar blurs the editor and commits.
• It's inconsistent with the app's own convention — everywhere else, inline editors commit on blur.
• It's contrary to the macOS norm (Finder, Xcode's navigator, Notes): click-away confirms; Escape is the cancel gesture. A silent discard also loses typed input with no signal, which is the more damaging default.

Individual tab and pane renames are affected the same way, since CancelActiveRename cancels all three.

Suggested fix

If you agree the behavior should change: make the panel-background click finish the active rename instead of cancelling — or drop the CancelActiveRename dispatch entirely and let the editor's own Blurred → finish path run. No test currently covers commit-on-blur or click-away for any of the three rename flows; a regression test on the CancelActiveRename-vs-finish interaction would lock the chosen behavior in.

Related: #10580.

Environment

• Warp: 0.2026.07.08.17.54.02 (stable)
• macOS: 27.0 (26A5388g)

[warp-for-oss]

@fbartho

Here's what I found while triaging this issue:

Thanks for the detailed repro. This appears actionable from the current vertical-tabs rename flow, and I do not think more reporter information is needed before maintainer review.

Maintainer details

I concluded that clicking the vertical-tabs panel background during an inline tab, pane, or tab-group rename cancels the active rename instead of allowing the editor's blur handler to commit it..

Initial triage

This looks like a reproducible vertical-tabs rename bug/design inconsistency rather than a support issue. The inline rename editors for tabs, panes, and tab groups already finish on EditorEvent::Blurred | EditorEvent::Enter, but the vertical-tabs panel background click path dispatches WorkspaceAction::CancelActiveRename, whose handler cancels all three rename states. Once the rename state is cleared, the blur-to-finish path has no active rename left to commit, so the typed name is discarded.

Reproducibility: High. The report includes concrete steps and environment details, and the code path matches the described behavior.

Likely area: Window/tab/pane management, specifically vertical-tabs inline rename handling.

Duplicate check: I enumerated open issues with the GitHub API and found related rename/group issues, including #14241 for focus stealing during group creation and #10580 for exposing rename/color actions, but not two existing issues matching this click-away-discard behavior.

Suggested next step: A narrow fix would change the vertical-tabs background-click behavior to finish the active rename or allow the editor blur handler to run, while keeping Escape as the explicit cancel path. Add regression coverage for tab, pane, and tab-group rename interactions around background click versus blur/Enter/Escape.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[bholmesdev]

@oz-agent implement a fix where we commit a rename for both tabs and tab groups on blur

[warp-for-oss]

@bholmesdev

Here's what I found while triaging this issue:

This looks reproducible from the current implementation: clicking the vertical-tabs panel background cancels the active rename instead of letting the existing blur-to-commit path run. Escape should remain the explicit cancel gesture.

I've flagged this for the factory auto-implement queue.

Maintainer details

I concluded that clicking the vertical-tabs panel background while a tab or tab group rename is active cancels the rename before the existing blur-to-commit editor path can run..

Triage

This is a high-confidence client-side bug in vertical-tabs rename handling. The report includes clear reproduction steps and the current code supports the described event-flow conflict.

Reproducibility

High. The active rename editors already finish on blur/Enter, but the vertical-tabs panel background click currently sends a cancel action first.

Likely root cause

app/src/workspace/view/vertical_tabs.rs:1728 dispatches WorkspaceAction::CancelActiveRename from the panel background click handler. app/src/workspace/view.rs:23962 then handles that action by calling cancel_tab_rename, cancel_pane_rename, and cancel_tab_group_rename, clearing rename state before the editor blur handlers can commit through finish_tab_rename, finish_pane_rename, or finish_tab_group_rename.

The existing editor event handlers in app/src/workspace/view.rs:1481, app/src/workspace/view.rs:1499, and app/src/workspace/view.rs:1520 already treat Blurred | Enter as commit and Escape as cancel, so the likely fix is localized to the panel-background cancel behavior and associated tests.

Duplicate check

I checked all open issues and recently closed issues for matching rename/click-away/blur symptoms. Related issue #10580 concerns exposing rename actions in a pane header menu, and the closest open candidates concern accidental rename activation, launch-config persistence, group-creation focus stealing, or AI title overwrites; fewer than two likely duplicates were found.

Implementation notes

The trusted maintainer comment asks for a fix where tab and tab-group renames commit on blur. A narrow implementation should preserve Escape as the explicit cancel gesture and add regression coverage for tab and tab-group rename click-away/blur behavior.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz