Describe the bug
In the tab context menu (vertical tabs), clicking a row that opens a submenu, such as Move to group ›, closes the submenu. It stays closed while the pointer remains on that row. It only reopens after the pointer leaves the row and comes back.
Hovering the row opens the submenu correctly, so the bug shows up when someone clicks the row before moving on, which is a natural thing to do with a row that has a › on it.
To reproduce
- Open a window with at least three tabs in vertical tabs.
- Right-click the first tab and choose New group with tab.
- Right-click a tab that isn't in the group.
- Hover Move to group ›. The sidecar opens and lists the group.
- Click Move to group ›.
- The sidecar closes. Moving the pointer within the same row does not bring it back.
Expected behavior
Clicking a submenu parent row keeps the submenu open (or opens it if it wasn't open yet).
Environment notes
I reproduced this on a local OSS build of master at 25e82210a, plus an unrelated change that is off by default and does not touch the menu or sidecar code. I haven't checked a released build, so I can't say whether the released app behaves the same.
The sidecar is shown from update_move_to_group_sidecar in app/src/workspace/view.rs on MenuEvent::ItemHovered | ItemSelected. That path appears to hide the sidecar on the click, and then no further hover event fires while the hovered row index is unchanged.
Operating system (OS)
macOS
Operating system and version
macOS 27.0.1
Shell Version
zsh
@nickvirden
Here's what I found while triaging this issue:
Thanks for the detailed reproduction steps. This looks actionable as a tab context-menu bug: clicking the Move to group › parent should keep its sidecar available rather than requiring the pointer to leave and re-enter the row.
I've flagged this for the factory auto-implement queue.
Maintainer details
I concluded that clicking the vertical-tabs "Move to group" submenu parent closes its sidecar until the pointer leaves and re-enters the row..
Triage summary
This is a client UI bug in the vertical-tabs tab context menu. The report gives a clear path: create a tab group, open another tab's context menu, hover Move to group ›, then click that parent row; the sidecar closes and does not reopen until the pointer leaves and re-enters the row.
Reproducibility is high from the provided steps and local build context. Code inspection points to the custom sidecar flow around
update_move_to_group_sidecarand the generic menu hover/selection/close handling: the "Move to group" parent is rendered as a submenu-like menu item, and the sidecar visibility is coupled to the parent menu's hovered row state.No confirmed duplicate cluster was found after scanning open issues and recent closed issues; the closest search hits are broader or different tab-group/context-menu requests.
This appears eligible for factory auto-implementation: the expected behavior is unambiguous, the likely fix is localized to the client menu/sidecar interaction, and no reporter follow-up is needed before implementation.
This is my automated analysis and may be incorrect. A maintainer will verify the details.
Powered by Oz