Scrolling randomly stops working

[teo1978]

Usually, scrolling in the terminal window works as expected, which is like this:
- the terminal window has a scrollbar
- Assuming there are more lines (of commands you have typed + their output) than fit in the window, you can scroll up and down both by dragging the scrollbar and by using the mouse wheel

However, at random times, the Terminal starts behaving like this:
1 - the scrollbar's "handle" is as high as the whole scrollbar, as if the existing lines didn't exceed the height of the window, even if that is not the case
2 - you can't scroll by dragging the scrollbar (which is consistent with 1)
3 - the scrollwheel behaves like the up and down arrow keys, that is, it scans through previously typed commands in your history.

I have no idea what triggers the nonsense behavior. It seems to start happening randomly.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: gnome-terminal 3.16.2-1ubuntu4
ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
Uname: Linux 4.2.0-34-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 5 19:05:18 2016
InstallationDate: Installed on 2013-10-11 (906 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to wily on 2016-01-18 (78 days ago)

[Egmont Koblinger (egmont-gmail)]

The behavior you describe happens when the terminal switches to the so-called "alternate screen" upon encountering a certain escape sequence that is printed by your application. Usually fullscreen applications (such as the "mc" file manager, "less" pager, text editors etc.) use this mode.

If it gets stuck in this mode at your shell prompt, it means that your application did not exit cleanly and left the terminal in this mode. Execute the "reset" command to get out of this situation.

[teo1978 (teo8976)]

> If it gets stuck in this mode at your shell prompt,

yes it did

> it means that your application did not exit cleanly and left the terminal in this mode.

The very fact that that can happen is a bug. After exiting whatever application triggered "alternate screen", normal scrolling should be reestablished. The terminal shouldn't rely on applications exiting cleanly.

Also note that the behavior described at point (3) (the scrollwheel behaving like the up and down keys) makes no sense, it's inconsistent, useless and annoying. It should be eliminated altogether.

[Egmont Koblinger (egmont-gmail)]

> The terminal shouldn't rely on applications exiting cleanly.

You misunderstand the very basics of terminals.

A terminals just obeys the instructions it receives in a single stream, it doesn't even have the notion of "shell", "application" (started from that shell), "exit" (of that shell), "clean" vs. "unclean" exit, etc. It cannot tell which instruction comes from which component.

The best you can do is modify your shell prompt: add escape sequences that restore as many properties as you wish to their default. E.g. leave alternate screen, disable mouse, restore charset, restore color and so on.

You might want to file another bugreport so that the distribution's default PS1 shell prompt takes care of this.

Re (3): It's an intentional feature that in alternate screen mode, if the application running inside the terminal is not interested in mouse events, mouse scroll events are converted to Up/Down keystrokes.

[Egmont Koblinger (egmont-gmail)]

... "exit" (of that *application*) ...

[teo1978 (teo8976)]

> A terminals just obeys the instructions it receives in a single stream,
> it doesn't even have the notion of "shell", "application" (started from that shell),
> "exit" (of that shell)

Mmm, I probably do misunderstand something, but then I'm under the impression this might just be a bug in the shell rather than the terminal.

When in the shell I write "vim", then I use vim for a while, and finally exit it, maybe the terminal itself knows nothing about that but the shell does, right? becaue it's the shell that launched vim...

[Egmont Koblinger (egmont-gmail)]

That's right.

By convention, the expected behavior is that vim restores the terminal's settings. If it exits uncleanly, it might leave the terminal in a nondefault state, to which usually typing "reset", or closing the terminal and opening a new one might be an easy workaround.

I've always wondered why distributions don't set up a default shell prompt that resets some of the terminal options. I think it would be a good idea. Anyway, this does not belong to gnome-terminal but rather to bash.

[teo1978 (teo8976)]

Is that any reason why bash shouldn't always restore the the terminal settings after any program it launches exits? (where by "restore" I mean restore the settings as they were before launching the program, not necessarily the default ones).

[teo1978 (teo8976)]

Errata: by "is that" I meant "is there", of course

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[MightyPork (mighty-pork)]

Getting this with 1.91 on Arch, it likes to happen during package updates for some reason.

I found a hacky workaround - add this to your $PS1:

\[\e[?1049l\e[?2004l\e[?1006l\e[?1002l\e[?1001r\e[?1l\]

It'll fix it as soon as you get to a prompt.

Given how randomly it happens, I believe there is a real bug in Terminator; but if you want to force the broken state, just open 'mc' and run 'pkill mc' from another terminal, your scrolling will be broken.

A way to debug this kind of thing is to run e.g 'mc > trace.txt'. Then type 'exit', hit return, and mc will quit. You will get all the escape sequences from mc in trace.txt to inspect.

[MightyPork (mighty-pork)]

oops this is a wrong place to report it as a terminator bug, but the workaround should work anyway ;)

[Egmont Koblinger (egmont-gmail)]

> I found a hacky workaround - add this to your $PS1:

The workaround of resetting relevant settings from the prompt has already been mentioned – although without showing a concrete example.

> Given how randomly it happens, I believe there is a real bug in Terminator

I'm about 99.999% sure that this is _not_ a bug in Terminator (VTE). It is believed to properly execute the relevant escape sequences it receives. (Can you reproduce the issue with xterm, urxvt, konsole...? I bet you can.)

> but if you want to force the broken state, just open 'mc' and run 'pkill mc' from another terminal, your scrolling will be broken.

Yup, in this case mc asks the terminal to switch to a special mode, and due to getting killed, it does not ask the terminal to leave that mode. Nothing new here, exactly what has already been concluded in this thread.

> run e.g 'mc > trace.txt'. Then type 'exit', hit return, and mc will quit. You will get all the escape sequences from mc in trace.txt to inspect.

Can you really reproduce the issue this way? Because you don't kill mc now, but exit it cleanly.

> to report it as a terminator bug

Unless you have firm evidence that this is a terminator (or VTE) bug, please don't spam its bugtracker with something that's most likely an issue elsewhere.