Switching panes in multiple directions at once causes the focused pane to rapidly switch when any key is pressed

[illode]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

KDE Plasma 5.27.8

WezTerm version

20231002-075348-a61cc8eb

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

If I try to change to two different panes e.g. Alt+Left+Right (using my keybinds), the pane switching completely breaks. It doesn't always happen, but it happens often enough to be a huge pain.

It's easiest to explain with a video:

https://github.com/wez/wezterm/assets/114271894/99963be2-2517-4779-a976-938c12504d46

First I spam switch panes with Alt+Random Arrow Key (custom keybind), then once it breaks I spam a random key (z). You can see the focus randomly flicker between panes.

To Reproduce

1. Use my configuration
2. Create multiple panes (Ctrl+p -> s -> <Arrow Key> with my config, but I don't think it really matters how they're made)
3. Switch to multiple panes at once using Alt+<Up>+<Right> or some other combination of arrow keys. There must a pane in the directions pressed for it to break.

Configuration

local wezterm = require 'wezterm'
local act = wezterm.action


return {

  -- Keyboard Shortcuts
  leader = { key = 'p', mods = 'CTRL', timeout_milliseconds = 5000 },

  keys = {
    -- Key Tables
    { key = 'r', mods = 'LEADER', action = act.ActivateKeyTable { name = 'resize_pane', one_shot = false } },
    { key = 's', mods = 'LEADER', action = act.ActivateKeyTable { name = 'split_pane', one_shot = true } },
    { key = 'm', mods = 'LEADER', action = act.ActivateKeyTable { name = 'move_pane', one_shot = false } },

    -- Close Active Pane
    { key = 'w', mods = 'LEADER', action = act.CloseCurrentPane { confirm = false } },    
    -- Change Active Pane
    { key = 'LeftArrow', mods = 'ALT', action = act.ActivatePaneDirection 'Left' },
    { key = 'RightArrow', mods = 'ALT', action = act.ActivatePaneDirection 'Right' },
    { key = 'UpArrow', mods = 'ALT', action = act.ActivatePaneDirection 'Up' },
    { key = 'DownArrow', mods = 'ALT', action = act.ActivatePaneDirection 'Down' },

    
  },

  key_tables = {
    split_pane = {
      { key = 'LeftArrow', action = act.SplitPane { direction = 'Left' } },
      { key = 'RightArrow', action = act.SplitPane { direction = 'Right' } },
      { key = 'r', action = act.SplitPane { direction = 'Right' } },
      { key = 'DownArrow', action = act.SplitPane { direction = 'Down' } },
      { key = 'd', action = act.SplitPane { direction = 'Down' } },
      { key = 'UpArrow', action = act.SplitPane { direction = 'Up' } },

      { key = 'Escape', action = 'PopKeyTable' },
    },
  }
}

Expected Behavior

Pane switches without issue

Logs

14:30:54.988  ERROR  wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
12:43:27.272  ERROR  wezterm_gui::frontend > Error reconciling PaneFocused notification: pane 0 not found
12:43:27.272  ERROR  wezterm_gui::frontend > Error reconciling PaneFocused notification: pane 1 not found

Anything else?

• The broken pipe error from the logs doesn't always appear. Additionally, if too many inputs are given in a short time, the focus will keep flickering after I stop pressing keys for a bit. The message doesn't seem to appear until after the flickering stops. It always appears once.
• The pane not found errors in the logs only appear once I close the wezterm GUI window.
• Zooming in then out of a pane with Ctrl+Shift+z fixes the main problem, but if a TUI (helix, in my case) is open, the pane with the TUI sometimes (not always) become unresponsive and needs to be closed anyways.
• If I use one keybind at a time (e.g. Alt+Right then Alt+Up) instead of combining them (Alt+Right+Up) then it doesn't break.
• I run into this issue far more frequently on my laptop than on my desktop despite using the keybinds the same amount, to the point where I'm willing to use panes despite the risk on my desktop, but avoid them on my laptop. I assume it's due to the hardware difference (i7-1185G7 + 32GB RAM vs 7950x3d + 64GB RAM + 6900xt), but I'm not sure.
• While it's stuck flickering between panes, no new wezterm GUI windows can be opened without the start --always-new-process args. Once the buggy window is closed or fixed by zooming in/out, all the queued GUI windows will open.

[crides]

This seems to be the exact same behaviour when I got #4517 (but I didn't have time to find a repro method)

[osandov]

I opened PR #4737 fixing this (I think), which you may want to test out. Happy New Year!

[huylv]

My work relies heavily on using terminal over SSH. I never liked tmux and found out wezterm mux worked really well so I started using it. However, when I have multiple panes, and I open a third window or resize the current one, the focus keeps switching between mux panes and a lot of errors spew out: ERROR wezterm_gui::frontend > Error reconciling PaneFocused notification: pane X not found. It's really annoying and sometimes unworkable :(

So, is there any update to this issue? I'm really looking forward to a fix for this issue.

[illode]

My work relies heavily on using terminal over SSH. I never liked tmux and found out wezterm mux worked really well so I started using it. However, when I have multiple panes, and I open a third window or resize the current one, the focus keeps switching between mux panes and a lot of errors spew out: ERROR wezterm_gui::frontend > Error reconciling PaneFocused notification: pane X not found. It's really annoying and sometimes unworkable :(

So, is there any update to this issue? I'm really looking forward to a fix for this issue.

I haven't seen the issue in a while, and with a quick test I'm not able to reproduce it anymore on at least one of my machines. Said machine has wezterm 20240203-110809-5046fc22.

I'm not sure if this would work over SSH / still works, but if I remember right, I was able to un-break it by zooming into and out of a pane. The default keybind is Ctrl + Shift + Z.

[manpreetmaso]

Happens all the time on Fedora x86_64 and aarch64 especially over SSH. Focus flips between panes and does not stop. I have to resort to killing wezterm and resrtart.

[huylv]

@illode: Here's how to reproduce it consisntently.

1. Connect to a remote session: wezterm connect <my-server>
2. Split the window into 2 panes
3. Open another window (by now there are two windows, one with 2 panes, the other is not split)
4. On the unsplit window, print some long text: for i in {1..1000}; do echo foo; done
5. Click the split pane, the focus will keep switching between the 2 panes

Note: the error ERROR wezterm_gui::frontend > Error reconciling PaneFocused notification: pane X not found might or might not appear, I don't know yet the exact scenarios, but it does appear frequently.

My client is Ubuntu 22.04 LTS and my server is Redhat 9. I have tried both the stable release and the latest nightly build.

[illode]

@huylv I still can't reproduce my original issue with those steps. The only thing I can reproduce is that if I:

1. `wezterm connect
2. Split server into several panes
3. Spam the switch pane hotkey

After spamming for a few seconds, the entire window hard lags/hangs. The timing is pretty consistent, so it seems like some buffer might be filling out? Not quite sure. Just closing the window reconnecting fixes the issue.

ATM I don't have a machine outside of LAN to test with though, so if network latency is part of the problem, it likely wouldn't affect me.

Also when you say:

Open another window (by now there are two windows, one with 2 panes, the other is not split)

You mean you have one window that's connected to the server, and one that's just a normal local wezterm instance, right? Because I'm not sure how it's possible to get two windows connected to the same domain.

If you only get it with multiple windows, you could try starting all your wezterm gui windows with --always-new-process. I started doing that at some point because I would have a single window that would crash (unrelated issue), and since the windows share state, it would take all the other windows out with it.