Fix Ctrl+Tab palette getting stuck on fast presses#11222
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @simone-panico on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment |
|
This PR is not linked to an issue that is marked with Issue-state enforcement details:
To continue, link this PR to a same-repo issue such as Powered by Oz |
There was a problem hiding this comment.
This PR is not linked to an issue that is marked with ready-to-implement.
Issue-state enforcement details:
-
Associated same-repo issues checked: none
-
Required readiness label:
ready-to-implement
To continue, link this PR to a same-repo issue such as Closes #123 in the PR description, and make sure that issue has ready-to-implement.
Powered by Oz
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
Description
Problem
When pressing Ctrl+Tab quickly, the MRU palette would sometimes stay open instead of switching tabs. You'd have to press Ctrl again to dismiss it.
The palette commits its selection when it receives the Ctrl-release event via its own
on_modifier_state_changedlistener. That listener is part of the palette's render tree, so it only fires once the palette has been added to the rendered scene. On a fast press you can release Ctrl before the next frame renders the palette, so the release event passes through the workspace and is lost.There was also a secondary bug in
open_palette: when opened via Ctrl+Tab it focusesself.paletteinstead ofself.ctrl_tab_palette, sending focus to a view that isn't even mounted.Solution
Two small changes in
app/src/workspace/view.rs:on_modifier_state_changedon the workspace root. Thanks to child-first event dispatch, it only fires when the palette isn't in the scene yet, i.e. the bug case. It dispatches a newWorkspaceAction::CtrlTabPaletteCommit, whose handler usesdispatch_typed_action_deferredto queueAction::CtrlPressed(false)targeted at the palette. Deferring is necessary because the palette's commit path synchronously re-enters the workspace viaroot_view:activate_tab_by_pane_group_id, which would otherwise panic with "Circular view update".Normal (slow) Ctrl+Tab is unchanged: the palette's own listener handles it and stops propagation before the workspace fallback runs.
Linked Issue
#11221
ready-to-specorready-to-implement.Testing
./script/runCHANGELOG-BUG-FIX: Fix Ctrl+Tab palette getting stuck open when releasing Ctrl quickly