Improper handling of combined focus+resize events on master and 3.3.1

[gravndal]

In tmux with $ tmux set focus-events on fish will put "garbage" in the command line when it receives/loses focus after closing/creating a split window.

Bisect:

7c153a8307c662fa853280fd64657dff0cd9a625 is the first bad commit
commit 7c153a8307c662fa853280fd64657dff0cd9a625
Author: ridiculousfish <rf@fishshell.com>
Date:   Sat Apr 10 20:41:33 2021 -0700

    Introduce prepare_to_select, fixing job_summary.py

    This concerns printing status messages for background jobs which have
    stopped or finished. Previously fish would do this from two places:

    1. Before running a command (including empty string)
    2. If a signal is received during select()

    So if the job finishes while fish is doing something else (like running an
    event handler) then we would not print status messages until the user hit
    return. This caused the job_summary.py test to be flaky.

    Fix this by splitting the interrupt handler into two parts: a part that
    handles signals (e.g. triggering exit from the reader), and a part that
    always runs just before blocking in select(). This second part always
    reaps jobs and prints their status messages. This narrows the window for a
    job exit to be "missed" before fish blocks in select, and should make the
    job_summary.py test more reliable.

 src/input.cpp        | 13 +++++++++----
 src/input.h          |  3 +++
 src/input_common.cpp |  7 +++++++
 src/input_common.h   |  4 ++++
 4 files changed, 23 insertions(+), 4 deletions(-)

Tested on both Arch Linux and NixOS unstable.

Recording of observed behaviour in the linux tty on a clean nixos vm: https://asciinema.org/a/ODR7cnvio1vcaaZIdvFfe3oiJ

See #8628 (comment) for steps to reproduce.

[faho]

The "garbage" you are seeing is the tmux focus sequences. Apparently your fish doesn't react to it.

See if bind \e\[I and bind \e\[O print the correct thing:

> bind \e\[I
bind --preset \e\[I 'emit fish_focus_in'
> bind \e\[O
bind --preset \e\[O false

Also please show the output of bind --user.

[gravndal]

Those both print the correct thing, and bind --user has no output as this is without any user level configuration.

[gravndal]

Tried it on a different (much slower) machine: it reproduces, though not on every split/close, it's quite rare actually.

Looking closer, it also doesn't happen on every split on the faster machine, though it's an almost every time thing.

[gravndal]

Also if you or anyone else are curious here's a reproducing flake.{nix,lock} that can be compiled/ran with:

$ rm nixos.qcow2; nixos-rebuild build-vm --flake path:(pwd)#repro && ./result/bin/run-nixos-vm

{
  inputs = {
    nixpkgs = { url = "github:nixos/nixpkgs/nixos-unstable-small"; };
  };

  outputs = { self, nixpkgs }:
  {
    nixosConfigurations = {
      repro = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [ ({ pkgs, ... }: {
          console.keyMap = "colemak";
          users.users.a = {
            password = "a";
            isNormalUser = true;
          };
          nixpkgs.overlays = [
            (self: super: {
              fish = super.fish.overrideAttrs (oldAttrs: {
                src = self.fetchFromGitHub {
                  owner = "fish-shell";
                  repo = "fish-shell";
                  rev = "1eb58f905449fb3af9bf79bf2589df47f544c9cb";
                  sha256 = "ajoyk7t6tQjFWwqSbnFugeesYBB+QnSiTHC3njqaFNA=";
                };
                doCheck = false;
              });
            })
          ];
          environment.systemPackages = with pkgs; [
            fish
            tmux
            asciinema
          ];
        })];
      };
    };
  };
}

{
  "nodes": {
    "nixpkgs": {
      "locked": {
        "lastModified": 1641789839,
        "narHash": "sha256-go3JSvI/h0IO7l7RO60WD+7KS8DmRWVrm2UQBzId8H4=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "6efb39682f9c007608eb966681a11a91fcbf0c9c",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixos-unstable-small",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs"
      }
    }
  },
  "root": "root",
  "version": 7
}

Though you might want to remove/change console.keyMap = "colemak";.

[faho]

What's the latest commit you tried? The one you bisected it to seems quite unlikely.

[gravndal]

1eb58f9 which is to say master as of an hour ago.

The bisect was with good 3.2.2 and bad 3.3.1.

[faho]

I just tested on the second machine, all I can tell you is it works for me. You'll want to check all fish and tmux configuration, and this includes the system-wide configuration in /etc/fish, and the vendor configuration in (typically) /usr/share/fish/vendor_conf.d.

Typically what would cause something like this to show up, especially sometimes, is if your escape delay is set to a too small value. That would cause fish to read the escape as a separate keypress and then read the [I as ordinary presses of [ and I. This would then be inserted into the commandline.

But the default escape delay is 30 milliseconds, which should be plenty. This is configurable via $fish_escape_delay_ms.

(unfortunately there is no better way to tell the difference in a terminal, other programs also have this notion, including things like emacs and vim)

You'll also want to check if your terminal matters. Try a different one, see if that messes it up. Some have shell integration that sometimes has bugs.

[gravndal]

Here's a fish profile for a run where it triggers a few times: https://gist.github.com/gravndal/992ce4c0c2eb733605f83b355ed20ef3

For configuration, when testing in the vm the home directory is empty on login. As for system-wide, unless I'm blind, there is none:

• /etc/fish doesn't exist
• all vendor_*.d directories are empty
• same thing with tmux

Increasing $fish_escape_delay_ms to 4999 changes nothing.

Of the two terminals I've tried — the linux console/tty in a qemu vm, and alacritty — neither have shell integration. Also just tried XTerm(370), didn't make a difference.

Nix does some stuff to ensure that fish sources the correct runtime, however given that this reproduces fine on arch, that shouldn't matter.

The tmux version is 3.2a with the following patch backported tmux/tmux#2755.

[faho]

What I can see from that profile is that

1. This is quite slow for you - 80ms for emit fish_focus_in (with no discernable handler) vs 0.03ms for me.
2. It appears to be running the signal handler for SIGWINCH right after, and I don't know why

I guess it might be possible that we read escape, then get a signal handler and only then get the [I part. If we misinterpreted that as no longer belonging together it might trigger this. It seems unlikely - why would you constantly get a WINCH right in the middle of the sequence that tmux presumably writes at once? @ridiculousfish might have an idea.

Nix does some stuff to ensure that fish sources the correct runtime, however given that this reproduces fine on arch, that shouldn't matter.

Nix does some more stuff. Can you reproduce this with https://aur.archlinux.org/packages/fish-git/, or building fish yourself, manually?

[gravndal]

Profile for fish-git (3.3.1-838-g1eb58f905) on arch: https://gist.github.com/gravndal/590fb3fc0bee1c4cbe391d90182d9c31

Note that the first Prefix-" + ^D that causes fish to misbehave is right after the echo $version.

This was on a new user with an empty $HOME, and tmux was ran with -f /dev/null (and manually setting focus-events on).

[faho]

Note that the first Prefix-" + ^D that causes fish to misbehave is right after the echo $version.

Hold on. Now you're saying ^D, which is traditional notation for ctrl+d. Are you pressing something else? Is anything but [I or [O showing up?

Anyway, we again have:

23	23	> emit fish_focus_in
49	133	> __fish_winch_handler SIGWINCH

A focus event immediately followed by a winch signal.

[gravndal]

To trigger it I'm just repeatedly splitting with Prefix-" and immediately closing the split, as you saw in the asciinema rec in the op, by exiting the new shell with ctrl-d.

Edit: And no, nothing but [I or [O shows up.

[gravndal]

You can also try automating with something like this (assuming a nested tmux session):

for i in (seq 100)
    tmux send-keys -t :0.0 'C-b' \"; sleep 0.05; tmux send-keys -t :0.0 'C-d'
    sleep 0.5
end

Though it appears that only [O misbehaves when doing this:

[faho]

You can also try automating with something like this (assuming a nested tmux session):

Sorry, I have no idea how I would setup a "nested tmux session". I don't use tmux.

And it doesn't really matter, by now I've created and switched and quit panes enough that I'm confident it's not happening on my system.

Something on your system is different.