mirror of
https://github.com/zed-industries/zed.git
synced 2026-08-21 23:14:27 +00:00
b005c0de67
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> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| LICENSE-GPL | ||