diff options
| author | user <user@clank> | 2026-08-08 22:08:09 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-08 22:08:09 +0200 |
| commit | 1417b7295863945c540d669f18a913cde6ee13b0 (patch) | |
| tree | 54fae0390f116a1dec7f57d10e765333a838236e /default-plugins/plugin-manager | |
| parent | sl0p: fix double-click-to-rename, which never fired (diff) | |
| download | sl0ppij-1417b7295863945c540d669f18a913cde6ee13b0.tar.gz sl0ppij-1417b7295863945c540d669f18a913cde6ee13b0.tar.xz sl0ppij-1417b7295863945c540d669f18a913cde6ee13b0.zip | |
sl0p: don't let hover steal focus while typing into a rename prompt
Reported after double-click-to-rename landed: rename one pane, then hovering
over other panes puts them in 'edit title' state too.
Cause is focus_follows_mouse, not the rename itself. RenamePane is a CLIENT
mode that acts on whatever pane is ACTIVE, so with focus-follows-mouse enabled
every pane the mouse passes over becomes active and inherits the prompt. The
double-click entry point just made it easy to hit, since you finish the
gesture with the mouse sitting on a pane frame.
Focus-follows-mouse is now suppressed for a client that is in a modal
text-entry mode: RenamePane, RenameTab, EnterSearch or Prompt. Those all act
on the active pane/tab, so moving focus underneath them is never what the user
meant. Keyboard focus movement is untouched.
Baselines held: zellij-server 1429/30.
Diffstat (limited to 'default-plugins/plugin-manager')
0 files changed, 0 insertions, 0 deletions