Terminal mouse went berserk after lost ssh connection

[teo1978]

I'm not sure I assigned this issue to the correct package.

The bug is either in bash, or in Ubuntu's application terminal, the one that provides a terminal window to run bash in, which I think is xterm but I'm not sure.

Also this could be triggered by either an issue in ssh or in vim which is run on the remote server (see steps to reproduce below), BUT no matter whether or not there's actually a bug in either of them, the shell itself (or the terminal wrapper window) is almost certainly at fault for not being robust against that.

So let's get to the issue.

What reproduced it for me:

1. I opened a terminal in Ubuntu on my laptop
2. In that terminal, I connected to a remote server using ssh
3. Within ssh, on the remote server I ran vim
4. Several hours passed and I suspended my local laptop
5. I resumed from suspend and went back to the terminal

At this point the connection with the remote server was obviously lost, so as soon as I typed something, I was outside of ssh and in my local shell.

6. I ran some commands locally in the terminal (obviously starting with "clear" to clean up the mess left from quitting ssh while vim was open on the remote server)

7. I clicked and dragged within the terminal to select some text

EXPECTED: the mouse should behave normally as it usually does when you click and drag to select stuff in a terminal

OBSERVED: the terminal went berserk and for every movement of the mouse while the mouse button was pressed, a bunch of gibberish characters appeared.

Now, I understand that while I was connected to the remote server via ssh, and running vim on it, the mouse had a certain behavior, which implies that somehow information about the interaction of the mouse with the terminal is sent over to the server where vim reacts to it. And I understand that both vim on the server and ssh on the local machine exited abruptly when I suspended and resumed my computer, and/or because of the hours of inactivity.
So, I understand that something about the way the terminal window, or bash itself, handles mouse input, ramained in some unexpected status.

However, that that can happen is a bug. A ssh connection can be lost, and this possibility must be taken into account.
The responsibility of this cannot by definition belong to vim or any other software on the remote machine, because if the connection is broken there's nothing the remote machine can do to prevent bad stuff from happening on the local machine.

And I think the responsibility shouldn't fall on the ssh client either, because any program launched by the shell (such as in this case ssh) can die unexpectedly, or even behave malitiously, and once you exit from it, the shell itself (or the terminal window that hosts it) MUST restore its normal interaction with keyboard, mouse and whatever else.

However, if ssh is exiting gracefully after detecting a break in the connection, then of course it should do its best to not leave its parent shell in a mess of a state (even if the shell has a responsibility to not be left in a mess of a state by a misbehaving ssh that doesn't do its job properly when exiting).

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xterm 322-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-173.203-generic 4.4.208
Uname: Linux 4.4.0-173-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia
.proc.driver.nvidia.gpus.0000.01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0000:01:00.0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.107 Thu May 24 21:54:01 PDT 2018
 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
.tmp.unity_support_test.0:

ApportVersion: 2.20.1-0ubuntu2.23
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Mon May 4 18:40:15 2020
DistUpgraded: Fresh install
DistroCodename: xenial
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Acer Incorporated [ALI] 3rd Gen Core processor Graphics Controller [1025:0647]
 NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] [10de:1140] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Acer Incorporated [ALI] GeForce 710M [1025:0691]
InstallationDate: Installed on 2013-10-11 (2396 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Acer Aspire V3-571G
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-173-generic root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7
SourcePackage: xterm
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/15/2012
dmi.bios.vendor: Acer
dmi.bios.version: V2.07
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: VA50_HC_CR
dmi.board.vendor: Acer
dmi.board.version: Type2 - Board Version
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: V2.07
dmi.modalias: dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07:
dmi.product.name: Aspire V3-571G
dmi.product.version: V2.07
dmi.sys.vendor: Acer
version.compiz: compiz 1:0.9.12.3+16.04.20180221-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.91-2~16.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~16.04.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~16.04.1
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Fri Apr 17 02:39:40 2020
xserver.configfile: /etc/X11/xorg.conf
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.18.4-0ubuntu0.8

[Timo Aaltonen (tjaalton)]

pretty sure that's quite usual that the terminal get 'corrupted' in such cases, and you can get away with it by running 'reset' which resets the terminal emulation

[Egmont Koblinger (egmont-gmail)]

The same applies not just for the mouse mode, but a whole lot of other terminal modes (e.g. keypad modes, alternate charset, alternate scroll mode, bracketed paste mode, colors, attributes and many many more...).

The problem cannot be fixed in the terminal: The terminal, by design, only sees a single continuous stream of instructions to execute. It has no idea where they come from, e.g. remote or local, ssh or not. It cannot figure out when is the time to override those instructions.

A reasonable place to fix this would be the shell prompt (or a hardwired behavior of the shell, to reset these modes whenever it prints the prompt). You can customize your PS1 to include the escape sequence that switches off mouse mode, and whatever else you wish. (Don't forget to wrap these in \[ \] as per the PROMPTING section in bash's manual.)

I agree that either upstream bash, or downstream distributions by configuring PS1 accordingly, should do their best to minimalize the risk of such situations, i.e. reset as many of the terminal modes as reasonable. I myself used to do it in my personal PS1 until I got bored of maintaining it and stopped caring, the problems are so rare that I just execute "reset" or close the terminal and open a new one :)