menu: fix app menu action routing after hover switching#2321
Merged
madcodelife merged 1 commit intolongbridge:mainfrom Apr 30, 2026
Merged
menu: fix app menu action routing after hover switching#2321madcodelife merged 1 commit intolongbridge:mainfrom
madcodelife merged 1 commit intolongbridge:mainfrom
Conversation
Problem: Menu items could sometimes do nothing after switching between top-level menus by hovering. The menu was using the current focus when each popup opened. After the first popup opened, focus moved into that popup. When the user hovered to another menu, the new popup could accidentally remember the old popup as the place to send actions. That old popup was no longer active, so the selected menu item had nowhere useful to go. Solution: The menu bar now remembers the focused area once, when the menu interaction starts. It keeps using that same target while the user switches between menus, and clears it when the menu closes. Popup menus, including submenus and reused popups, now receive this stored target instead of reading focus again. This keeps menu actions routed to the view that was active before the menu opened, even after hover-switching between menus. Implemented-by: Codex GPT-5.5 High Reviewed-by: Claude Opus 4.7 High & Human Tested-by: Human
Member
|
Thank you. |
AzureZee
pushed a commit
to AzureZee/gpui-component
that referenced
this pull request
Apr 30, 2026
) **Problem:** Menu items could sometimes do nothing after switching between top-level menus by hovering. The menu was using the current focus when each popup opened. After the first popup opened, focus moved into that popup. When the user hovered to another menu, the new popup could accidentally remember the old popup as the place to send actions. That old popup was no longer active, so the selected menu item had nowhere useful to go. **Reproduce:** 1. Select Editor in Story 2. Select any text 3. Click the Help menu 4. Move to the Edit menu and select Cut Nothing happens. **Solution:** The menu bar now remembers the focused area once, when the menu interaction starts. It keeps using that same target while the user switches between menus, and clears it when the menu closes. Popup menus, including submenus and reused popups, now receive this stored target instead of reading focus again. This keeps menu actions routed to the view that was active before the menu opened, even after hover-switching between menus. > Implemented-by: Codex GPT-5.5 High > Reviewed-by: Claude Opus 4.7 High & Human > Tested-by: Human **Tests run using Story:** - Click menu A, click an item in menu A. - Click menu A, hover menu B, click an item in B. - Click menu A, hover B, hover C, click an item in C. - Open with click, switch menus with left/right arrow keys, press Enter on an item. - Open a menu, press Escape. Confirm focus returns to the original widget. - Open a menu, click outside it. Confirm focus returns and the menu closes. - Open a menu from widget 1, dismiss it, focus widget 2, reopen a menu. Confirm actions route to widget 2. - Use a submenu item, especially after hover-switching top-level menus first. - Trigger both focus-scoped actions, like copy/paste/delete, and global actions, like about/quit/theme, if present. - Try from different focused widgets: editor/input, sidebar/tree/list, and no obvious focused widget. ## Checklist - [x] I have read the [CONTRIBUTING](../CONTRIBUTING.md) document and followed the guidelines. - [x] Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate. - [x] Passed `cargo run` for story tests related to the changes. - [x] Tested macOS, Windows and Linux platforms performance (if the change is platform-specific) --- Hello - and thank you for this toolkit.
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
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.
Problem:
Menu items could sometimes do nothing after switching between top-level menus by hovering. The menu was using the current focus when each popup opened. After the first popup opened, focus moved into that popup. When the user hovered to another menu, the new popup could accidentally remember the old popup as the place to send actions. That old popup was no longer active, so the selected menu item had nowhere useful to go.
Reproduce:
Nothing happens.
Solution:
The menu bar now remembers the focused area once, when the menu interaction starts. It keeps using that same target while the user switches between menus, and clears it when the menu closes. Popup menus, including submenus and reused popups, now receive this stored target instead of reading focus again.
This keeps menu actions routed to the view that was active before the menu opened, even after hover-switching between menus.
Tests run using Story:
Checklist
cargo runfor story tests related to the changes.Hello - and thank you for this toolkit.