Don't cancel renames or dismiss Go to Line when the window is deactivated (#61852)
Closes #39286
## Problem
Switching the keyboard layout on Wayland (e.g. GNOME's Super+Space)
makes the compositor briefly grab the keyboard, which deactivates the
Zed window. GPUI reports window deactivation as a blur of the focused
element (`WindowFocusEvent` is emitted with an empty
`current_focus_path`), so controls that dismiss or cancel on blur
treated it as the user abandoning them. The same happens when switching
to another app window. As discussed in #39286 with @MrSubidubi, the
desired behavior is to keep these controls open and focused across
window deactivation.
## Fix
Guard the blur-driven cancel/dismiss handlers with
`window.is_window_active()`, following the pattern established for
pickers in #41320:
- Project panel: in-progress rename / new file / new directory inputs
are no longer cancelled when the window is deactivated
- Collab panel: in-progress channel rename is no longer cancelled
- Go to Line: the dialog is no longer dismissed
In-window focus changes (clicking elsewhere, Escape) keep the existing
commit/cancel semantics. The terminal tab rename needed no change: it
re-checks `FocusHandle::is_focused`, which reads `window.focus` and that
survives deactivation. Command palette, file finder, and outline were
already fixed by #41320.
Added a regression test (`test_rename_survives_window_deactivation`)
that starts a rename, deactivates the window via the test platform, and
asserts the edit state survives.
Two milder siblings were left unchanged to keep this PR focused,
flagging them for a maintainer decision: the notebook markdown cell
exits edit mode on blur (`crates/repl/src/notebook/cell.rs`), and the
diagnostics view prunes diagnosticless buffers on blur
(`crates/diagnostics/src/diagnostics.rs`).
Longer term it may be worth carrying the blur cause in the event itself
(e.g. a `FocusMoved` vs `WindowDeactivated` reason on `FocusOutEvent`
and `EditorEvent::Blurred`), so each handler has to state which causes
it handles instead of relying on an opt-in guard; happy to file a
separate issue for that.
## Before
https://github.com/user-attachments/assets/9eec1bb5-1881-4b3a-80ef-a287e23219ca
## After
https://github.com/user-attachments/assets/49b8775c-175a-4882-835d-871432c0b315
## Suggested .rules additions
> Handlers that cancel or dismiss UI on blur (`EditorEvent::Blurred`,
`on_blur`, `on_focus_out`) must check `window.is_window_active()` first:
GPUI reports window deactivation (app switch, layout switcher grabbing
the keyboard) as a blur of the focused element, and dismissing there
loses user input.
Release Notes:
- Fixed in-progress file renames, channel renames, and the Go to Line
dialog being cancelled when the window is deactivated, e.g. by a
keyboard layout switch on Wayland or by switching to another application
([#39286](https://github.com/zed-industries/zed/issues/39286)).
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
b005c0de67Mikhail Butvin committed on 7/29/2026, 12:49:46 PM· committed by GitHubparent007ffc7