ui: Dismiss context menus when window loses focus - #46866
Merged
danilo-leal merged 2 commits intoJan 15, 2026
Merged
Conversation
Context menus now close when the window becomes inactive (e.g., clicking to another window or app). Previously, menus would remain visible until the window regained focus. Uses `observe_window_activation` to detect when the window becomes inactive and calls `cancel` to dismiss the menu.
cla-bot
Bot
added
the
cla-signed
maxdeviant
changed the title
danilo-leal
enabled auto-merge (squash)
January 15, 2026 13:48
ConradIrwin
added a commit
that referenced
this pull request
Jan 28, 2026
This reverts commit d139c5e.
Merged
Member
|
I'm not sure why yet, but this seems to have caused two problems: the terminal lost focus when window switching, and the macOS emoji picker stopped working. I'm reverting in #47835 |
zed-zippy Bot
added a commit
that referenced
this pull request
Jan 28, 2026
Cherry-pick of #47835 to preview ---- - **Revert "ui: Dismiss context menus when window loses focus (#46866)"** - **Revert "Preserve and restore focus across window activation cycles (#47044)"** Closes #ISSUE Release Notes: - (preview only) Fixed typing emoji using the macOS system palette (cmd-ctrl-space) Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
Context menus close when the window becomes inactive (e.g., clicking to another window or app). Previously, menus would remain visible until the window regained focus. This aligns Zed's context menu behavior with native macOS apps, where NSMenu automatically dismisses when the window loses focus. Users expect menus to close when switching windows or apps. Uses `observe_window_activation` to detect when the window becomes inactive and calls `cancel` to dismiss the menu. Release Notes: - Fixed context menus dismiss/cancel when the window loses focus --------- Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
- **Revert "ui: Dismiss context menus when window loses focus (zed-industries#46866)"** - **Revert "Preserve and restore focus across window activation cycles (zed-industries#47044)"** Closes #ISSUE Release Notes: - (preview only) Fixed typing emoji using the macOS system palette (cmd-ctrl-space)
This was referenced Aug 1, 2026
butvinm
added a commit
to butvinm/zed
that referenced
this pull request
Aug 5, 2026
Window deactivation blanked the focus path in `Window::draw`, so every `on_blur` / `on_focus_out` listener fired as if the user had moved focus away, while `window.focus` and therefore `FocusHandle::is_focused` kept saying the handle was still focused. Controls that end an edit on blur destroyed user input whenever the user switched applications, or merely switched keyboard layout on Wayland, which is zed-industries#39286 and the one-control- at-a-time patches zed-industries#41320, zed-industries#46866 and zed-industries#47044 that preceded it. Window activation already has its own channel: `Window::active` is set before `activation_observers` run, and is exposed as `Context::observe_window_activation`. So the focus channel simply stops carrying it. `Frame::window_active` had no other reader and is deleted; `focus_lost_listeners` keyed off the raw paths and is unaffected. Consumers that genuinely want the deactivation signal move to a named helper, `Context::on_deactivated_while_focused`: the editor's hover popover, completion menu and edit prediction, and context menus. The terminal needs both edges for xterm focus reporting, so it observes window activation directly. The `is_window_active()` guards in the picker, project panel, collab panel and Go to Line become dead and are removed. Fixes zed-industries#39286
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
Context menus close when the window becomes inactive (e.g., clicking to another window or app). Previously, menus would remain visible until the window regained focus. This aligns Zed's context menu behavior with native macOS apps, where NSMenu automatically dismisses when the window loses focus. Users expect menus to close when switching windows or apps. Uses `observe_window_activation` to detect when the window becomes inactive and calls `cancel` to dismiss the menu. Release Notes: - Fixed context menus dismiss/cancel when the window loses focus --------- Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
- **Revert "ui: Dismiss context menus when window loses focus (zed-industries#46866)"** - **Revert "Preserve and restore focus across window activation cycles (zed-industries#47044)"** Closes #ISSUE Release Notes: - (preview only) Fixed typing emoji using the macOS system palette (cmd-ctrl-space)
butvinm
added a commit
to butvinm/zed
that referenced
this pull request
Aug 8, 2026
Window deactivation blanked the focus path in `Window::draw`, so every `on_blur` / `on_focus_out` listener fired as if the user had moved focus away, while `window.focus` and therefore `FocusHandle::is_focused` kept saying the handle was still focused. Controls that end an edit on blur destroyed user input whenever the user switched applications, or merely switched keyboard layout on Wayland, which is zed-industries#39286 and the one-control- at-a-time patches zed-industries#41320, zed-industries#46866 and zed-industries#47044 that preceded it. Window activation already has its own channel: `Window::active` is set before `activation_observers` run, and is exposed as `Context::observe_window_activation`. So the focus channel simply stops carrying it. `Frame::window_active` had no other reader and is deleted; `focus_lost_listeners` keyed off the raw paths and is unaffected. Consumers that genuinely want the deactivation signal move to a named helper, `Context::on_deactivated_while_focused`: the editor's hover popover, completion menu and edit prediction, and context menus. The terminal needs both edges for xterm focus reporting, so it observes window activation directly. The `is_window_active()` guards in the picker, project panel, collab panel and Go to Line become dead and are removed. Fixes zed-industries#39286
butvinm
added a commit
to butvinm/zed
that referenced
this pull request
Aug 16, 2026
Window deactivation blanked the focus path in `Window::draw`, so every `on_blur` / `on_focus_out` listener fired as if the user had moved focus away, while `window.focus` and therefore `FocusHandle::is_focused` kept saying the handle was still focused. Controls that end an edit on blur destroyed user input whenever the user switched applications, or merely switched keyboard layout on Wayland, which is zed-industries#39286 and the one-control- at-a-time patches zed-industries#41320, zed-industries#46866 and zed-industries#47044 that preceded it. Window activation already has its own channel: `Window::active` is set before `activation_observers` run, and is exposed as `Context::observe_window_activation`. So the focus channel simply stops carrying it. `Frame::window_active` had no other reader and is deleted; `focus_lost_listeners` keyed off the raw paths and is unaffected. Consumers that genuinely want the deactivation signal move to a named helper, `Context::on_deactivated_while_focused`: the editor's hover popover, completion menu and edit prediction, and context menus. The terminal needs both edges for xterm focus reporting, so it observes window activation directly. The `is_window_active()` guards in the picker, project panel, collab panel and Go to Line become dead and are removed. Fixes zed-industries#39286
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context menus close when the window becomes inactive (e.g., clicking to another window or app). Previously, menus would remain visible until the window regained focus.
This aligns Zed's context menu behavior with native macOS apps, where NSMenu automatically dismisses when the window loses focus. Users expect menus to close when switching windows or apps.
Uses
observe_window_activationto detect when the window becomes inactive and callscancelto dismiss the menu.Release Notes: