gnome-terminal unconditionally interprets mouse wheel events

[Matthias Klose]

Binary package hint: gnome-terminal

gnome-terminal started to translate mouse-wheel events into history scrolling, which doesn't work well when there's not a command prompt (another command running). this behaviour should at least be a configuration option; commands other than the shell may be confused by the escape codes sent as input.

[Áron Sisak (asisak)]

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>. We'd be grateful if you would then provide a more complete description of the problem.

[Micah Cowan (micahcowan)]

Please specify the versions of the libvte-common and gnome-terminal packages installed on your system.

What exactly do you mean by "history scrolling"? Do you mean that it scrolls through bash's command line history?

gnome-terminal should never send _any_ escape codes for mouse actions, unless it has specifically been asked to. Something has asked it to. Do you only encounter this action after running certain programs, or do you have a customized .bashrc?

Please move any .bashrc you have, to a temporary location (where bash won't read it by default, and open a new gnome-terminal. Does this behavior still occur?

(Áron, I hope you don't mind if I assign this one to myself, again.)

[Áron Sisak (asisak)]

Reassigning as Micah wanted.

[Chris Jones (cmsj)]

I have just upgraded my laptop (Thinkpad X40) to gutsy in the last few days and encountered this.

If I launch a regular gnome terminal and generate a lot of output (e.g. ls -la /etc/) and scroll with the mousewheel it moves back and forth through the history correctly.

If I then run screen inside the terminal and generate a lot of output, instead of behaving as above, the scrollwheel just does the equivalent of pressing up and down cursor keys - ie yes, it scrolls the command history.

I am able to reproduce this with an entirely new user with no bash, screen or gnome-terminal configuration. I am also able to reproduce it with a python script which uses vte. FWIW, I scroll using the middle mouse button and EmulateWheel (xorg.conf option). For me this is a regression from Feisty.

ii libvte9 1:0.16.6-0ubuntu2
ii gnome-terminal 2.18.1-1ubuntu

Please let me know if you need any more info.

[Chris Jones (cmsj)]

Sorry, that wasn't very clear.

With the regular gnome terminal without running screen, the mouse scrolls through the *scrollback* of the terminal (ie what you would expect since the widget has a scrollbar). It's just running inside screen that makes it scroll through command history, for me. Matthias - can you reproduce it outside of screen?

[Micah Cowan (micahcowan)]

For me, this happens in Feisty as well, though I suspect it depends on the version of screen running (potentially, remotely)--or possibly bash--rather than of gnome-terminal.

In order for such a thing to occur, bash must request screen to send it mouse button events, and screen must in turn request it of the "xterm"-like terminal running it. It seems likely that, for whatever reason, bash does not enable mouse-button support when running directly in gnome-terminal, but does when being run under screen. While it's hard to say for certain, my strong suspicion is that this is a bash issue, rather than a vte issue. However, as to whether this is truly a "bug", I'm not sure.

Note that, scrolling through the scrollback buffer when screen is active is useless anyway, since screen does not cause anything to be scrolled in the terminal; rather, it saves things to its own scrollback buffer, which can be accessed in "copy mode" (C-A C-[).

[Micah Cowan (micahcowan)]

Well, changing the TERM environment variable doesn't trick bash into sending that sequence. Perhaps bash won't request it, but will interpret them if they are sent unbidden.

Aha! If I run "screen cat", and scroll the mouse wheel, I get data. It's definitely looking like screen automatically requests mouse input, then, which it should not do. As I said previously, this is happening for me in Feisty (screen-4.0.3-0.2ubuntu2).

I'm reassigning this to screen, as that appears to be the culprit.

[Micah Cowan (micahcowan)]

Hm, I just noticed that Matthias never mentioned screen, however. Matthias, was screen involved when you experienced this bug? Otherwise, the issue Chris and I have just been discussing would be a separate issue (though, I suspect some program would still have had to invoke mouse reporting to produce your issue).

[Chris Jones (cmsj)]

fwiw, you can make screen send scrollback to the terminal with this in screenrc:

termcapinfo xterm ti@:te@

but I can reproduce the particular issue I mentioned with a fresh user (which presumably doesn't have that option since it's not enabled in /etc/screenrc).

[Matthias Klose (doko)]

> Hm, I just noticed that Matthias never mentioned screen, however.
> Matthias, was screen involved when you experienced this bug?

oops, didn't notice, that I didn't mention it. yes, this was seen with screen.

[John Dong (jdong)]

It's almost certainly caused by screen -- the mentioned termcapinfo line (also a variant is commented out in screenrc) "fixes" the problem. Maybe we should consider shipping that by default :)

[PETERV (bostonantifan)]

I added termcapinfo xterm ti@:te@ to my .screenrc, and now I can scroll in my screen windows. I love it. Thank you. I do have one question though. If I use the mouse wheel, or the up & down arrows of the scrollbar, the window scrolls, but snaps back to the bottom by itself. If I want to stay where I scrolled to I have to keep my mouse on the scrollbar slider and hold it in place. Makes it kind of difficult to do a cut & paste. Is there any fix for this? Also, I know this is off topic, but is there any way to get syntax coloring in vim when you're using screen? It works find outside of screen.
Thanks again....

[Heath Caldwell (hncaldwell)]

The problem is with vte (the terminal widget that gnome-terminal uses). A feature was added that sends a number of up/down keystrokes instead of regular scrolling if it is using the alternate screen or scrolling is restricted (one or both of which are the case when using ncurses applications).

I wrote a patch for vte to make the feature toggle-able, and a patch for gnome-terminal that allows you to turn it off or on for a profile. I filed a bug for this at:

https://bugzilla.gnome.org/show_bug.cgi?id=538195

You can get the patches there. Unfortunately, it looks like the vte developer isn't very receptive to the idea of making the feature configurable, which is kind of baffling to me.

The gnome-terminal patch makes the setting available under the "Scrolling" tab in the profile editor.

[Chris Jones (cmsj)]

Heath's comment and upstream bug suggest this is actually a VTE issue, rather than screen, so I have marked the Screen task as Invalid and added Ubuntu's VTE package and the upstream bugzilla report.

[Launchpad Janitor (janitor)]

This bug was fixed in the package vte - 1:0.17.2-0ubuntu2

---------------
vte (1:0.17.2-0ubuntu2) intrepid; urgency=low

  * Add 93_add_alt_screen_scroll_toggle.patch to solve scrolling-in-screen
    bug (http://bugzilla.gnome.org/show_bug.cgi?id=538195). Thanks to
    Heath Caldwell (LP: #106995).

 -- Kees Cook <email address hidden> Thu, 28 Aug 2008 09:24:06 -0700

[dnquark (leo-alekseyev+launchpad)]

I am seeing a similar behavior in screen under gnome-terminal under Ubuntu 9.10. I can scroll using ctrl-shift-arrows or ctrl-shift-page up/page down, but the mousewheel just goes through command history. With xterm and rxvt, mouse wheel scrolling works as expected.

[Otto Kekäläinen (otto)]

I have noticed the same problem when using gnome-terminal + mosh = mouse scroll goes trough command history (like pressing keys up and down) instead of scrolling the (as would be correct in that situation and what e.g. xterm does).

[Otto Kekäläinen (otto)]

Ok, the patch is now applied in gnome-terminal and I disabled in the profile the option 'Whether to send keystrokes for alternate screen scrolling' to fix this annoying behaviour for me.

[Guram Savinov (guram-savinov)]

93_add_alt_screen_scroll_toggle.patch
Why this patch isn't included in Ubuntu's 14.04 vte package?
http://packages.ubuntu.com/trusty/libvte-2.90-9

gnome-terminal calls vte_terminal_set_alternate_screen_scroll which is deprecated and do nothing in vte 0.34.9
http://packages.ubuntu.com/trusty/gnome-terminal
http://packages.ubuntu.com/trusty/libvte-2.90-9

/**
 * vte_terminal_set_alternate_screen_scroll:
 * @terminal: a #VteTerminal
 * @scroll:
 *
 * Since: 0.34.9
 * Deprecated: 0.34.9: This function does nothing.
 */
void
vte_terminal_set_alternate_screen_scroll(VteTerminal *terminal, gboolean scroll)
{
        /* We just want to export this symbol for compatibility */
}

It causes problems like this: mouse wheel sends key-up/key-down instead of scroll when GNU screen is run in gnome-terminal.

[Guram Savinov (guram-savinov)]

It seems that this commit in vte is related somehow:

commit 9f8c1b88dcd880c2d9e78c93521ee755560a9275
Author: Christian Persch <email address hidden>
Date: Mon Sep 30 23:00:09 2013 +0200

    emulation: Add support for DEC 1007 to set the alternate scroll mode

    By default, the mouse wheel sends cursor up/down keycodes in the
    alternate screen. This adds an escape sequence (DEC 1007) that allows
    turning this off (and on again).

    For compatibility with ubuntu's ******** patched vte, also add a
    (deprecated, skip) public API that has the expected name but does nothing.

    Based on patches from ubuntu, and Egmont Koblinger.

    https://bugzilla.gnome.org/show_bug.cgi?id=518405
    https://bugzilla.gnome.org/show_bug.cgi?id=709060

[Guram Savinov (guram-savinov)]

I've opened a new bug report: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1688528