# Don't cancel renames or dismiss Go to Line when the window is deactivated \(\#61852\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/b005c0de6728c65db431520647b2fb5c2887e14f)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: b005c0de6728c65db431520647b2fb5c2887e14f

Requested commit: b005c0de6728c65db431520647b2fb5c2887e14f

Commit: b005c0de6728c65db431520647b2fb5c2887e14f

Tree: 07edcc05fb34eb6c81a6442fe3912770ae34b354

Author: Mikhail Butvin

Committer: GitHub

## Message

```
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>
```

## Parents

- [007ffc790e653dda87f2f2f6276358f3a4e45c74](https://git.cafe/gitcafe/zed/commit/007ffc790e653dda87f2f2f6276358f3a4e45c74?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/b005c0de6728c65db431520647b2fb5c2887e14f?format=markdown)