The cause is screen; try without it. Note that if you have such a sensitive mouse, I suggest buying better one (you'd move the scroll back otherwise).

s/back/bar/

Thanks. Indeed it is a problem with screen (also mentioned for Ubuntu in https://bugs.launchpad.net/ubuntu/+source/screen/+bug/106995)

For anyone else coming across this report, adding:
   termcapinfo xterm ti@:te@

to screenrc sidesteps the issue.

In my case, the "termcapinfo xterm ti@:te@" trick works for vte<=0.16.2 but not works for vte>=0.16.9


In these newest versions of vte, the mouse wheel becomes "previous/next bash command history" in GNU screen and unable to scroll back the outputs.

To reproduce the bug:

1. open genome-terminal and run GNU screen within it.
2. use "ls -l" to generate enough outputs such that it scrolls
3. try using mouse wheel to scroll back the output (and it is not working)

Interestingly, without the "2." step, the mouse wheel still can scroll back, which indicates maybe something wrong with the checking of "scroll-back" and "previous history" in recent vte versions.

Created attachment 112656 [details] [review]
Fixes scrollwheel behavior on alternate screens

The misfeature is in vte.c function vte_terminal_scroll.

The issue is in the second large logic block - scroll events on an alternate screen.

There are two problems.   #1, the SCROLL wheel being used for "Up" and "Down" keys instead of PageUp/PageDown at about line 10331

The second is sending multiple keystrokes for a single mousewheel click.  This is caused by:

        adj = terminal->adjustment;
        v = MAX (1., ceil (adj->page_increment / 10.));

in the main section and

                gint i, cnt = v;

in the beginning of handling the alternate screen.

Both issues are fixed in this patch.

This is intentional.  If you are in alternate screen, the scrollwheel does otherwise nothing, so we made it send up/down keystrokes.  Workes great in vim, less, alpine, etc.  If you don't want, just don't use it. "Accidentally scrolled" is such a lame excuse.

It sounds like your termcap is broken, Behdad.  My VIM, less, top, etc work correctly with pageup/pagedown.  Which is what the scrollwheel should be sending, rather then arrowkeys.

It's utterly useless in command history, since it sends multiple arrowkey events for every 'click' of the wheel.

Sorry, but I just don't see this as the right thing to be doing.  Sending the keys the application is expecting for, you know, scrolling the screen, would make sense.  If your mouse has a console-style dpad control, that may make sense to use as arrows.

(In reply to comment #7)
> It sounds like your termcap is broken, Behdad.  My VIM, less, top, etc work
> correctly with pageup/pagedown.

Know of any terminal that sends pageup/pagedown on scrollwheel?  I was comparing to what everyone else does, which is "scrollwheel in alternate screen does nothing".

Note that ctrl+shift+pageup/pagedown used to scroll half screen each.  People found that quite unusable, so we've changed that to one-tenth of screen too.  That's what the scrollwheel does also.

> Which is what the scrollwheel should be
> sending, rather then arrowkeys.

According to whom?

> It's utterly useless in command history, since it sends multiple arrowkey
> events for every 'click' of the wheel.

So is sending pageup/pagedown.  They move to the very first and very last command in history.

> Sorry, but I just don't see this as the right thing to be doing.

Fair enough.

> Sending the
> keys the application is expecting for, you know, scrolling the screen, would
> make sense.

I don't see how that is the right thing to do either.

> If your mouse has a console-style dpad control, that may make
> sense to use as arrows.

My mouse does not have any scroll thingy.  But sure, that's the reason.  It's called scroll-wheel for a reason.

I've tested a few applications (on debian)

Bash: pageup/pagedown don't register.
      uparrow/downarrow move through the command history.

Less: pageup/pagedown scrolls a single page.
      uparrow/downarrow scrolls a single line.

vim:  pageup/pagedown scroll a single page.
      uparrow/downarrow move the cursor a single line.

ircii:pageup/pagedown don't register
      uparrow/downarrow move through command history (circular list)

bitchx: pageup/pagedown scroll through chat history
        uparrow/downarrow move through circular command history.

nano:   same as vim

alpine - message list
       pageup/pagedown scroll a single page
       uparrow/downarrow move a single message.

So we've got pageup/pagedown work as expected in 5 of the 7 programs tested, and don't do anything in the other two.  uparrow/downarrow work in 4 of the 7 programs, and produce unwanted effects in the other 3.

From this quick usability survey, I'd have to still reccomend using a single pageup/pagedown and letting the app handle scrolling.  Trying to fake it with uparrow/downarrow events seems more problematic.

(In reply to comment #9)
> I've tested a few applications (on debian)
> 
> Bash: pageup/pagedown don't register.

On all modern systems Bash goes to first/last in history.

> So we've got pageup/pagedown work as expected in 5 of the 7 programs tested,
> and don't do anything in the other two.  uparrow/downarrow work in 4 of the 7
> programs, and produce unwanted effects in the other 3.
> 
> From this quick usability survey, I'd have to still reccomend using a single
> pageup/pagedown and letting the app handle scrolling.  Trying to fake it with
> uparrow/downarrow events seems more problematic.

Except that a mouse-wheel "button" is not supposed to scroll a full page.  That makes the wheel completely unusable as rotating it totally gets you lost.

(In reply to comment #10)
> Except that a mouse-wheel "button" is not supposed to scroll a full page.  That
> makes the wheel completely unusable as rotating it totally gets you lost.

The mouse-weel is supposed to scroll. Whether by a full-page or half- that is for the application to decide. 

IMO vte should not be in the business of working around application bugs. If an application doesn't understand mouse buttons 4 and 5, then *the application* should be fixed rather than vte sending page-up/page-down/up/down. What is the difference between the scroll-wheel, and say buttons 6 or 7 (typically used for forward/backward in browsers)? Should vte be sending backspace or ctrl-left to applications? 

But if vte really must work around application bugs for usability reasons, that should be a (gconf) option that power users can disable. I don't think one can make a case for either page-up/page-down or up/down to *always* be the *right thing* to warrant removal of such an option.

When I say application,(In reply to comment #11)
> IMO vte should not be in the business of working around application bugs.

By which I include bugs in defining alternate screens.

(In reply to comment #11)
> (In reply to comment #10)
> > Except that a mouse-wheel "button" is not supposed to scroll a full page.  That
> > makes the wheel completely unusable as rotating it totally gets you lost.
> 
> The mouse-weel is supposed to scroll. Whether by a full-page or half- that is
> for the application to decide. 

And the "application" here is vte, cause that's the code receiving and handling scroll-wheel events.  The application running inside your terminal never gets scroll-wheel events, and has no way to do so.

The reason page-up/down is wrong for it is, because, well, those are "page" up/down.  Not single-unit-of-scroll-wheel-change up/down.]


> IMO vte should not be in the business of working around application bugs. If an
> application doesn't understand mouse buttons 4 and 5, then *the application*
> should be fixed rather than vte sending page-up/page-down/up/down. What is the
> difference between the scroll-wheel, and say buttons 6 or 7 (typically used for
> forward/backward in browsers)? Should vte be sending backspace or ctrl-left to
> applications? 

The difference is that vte does nothing with button 6/7, but vte uses buttons 4/5 to draw a scroll bar and scroll it when not in alternate screen mode.  In alternate screen, it decides to emulate that in some other way.

 
> But if vte really must work around application bugs for usability reasons, that
> should be a (gconf) option that power users can disable. I don't think one can
> make a case for either page-up/page-down or up/down to *always* be the *right
> thing* to warrant removal of such an option.

I would have agreed if there was another use for the buttons.  But "if you don't like the button, just don't press it" sounds like right to me.  It's like the reset button on your machine.

Or disable your 4/5 buttons using xmodmap if you keep pressing them accidentally.

(In reply to comment #13)
> And the "application" here is vte, cause that's the code receiving and handling
> scroll-wheel events.  The application running inside your terminal never gets
> scroll-wheel events, and has no way to do so.

I know nothing about terminal emulation, but I am pretty sure that an application can get mouse clicks (e.g. double clicking on a link inside w3m inside xterm) correct? Are buttons 1/2 treated unlike 4/5?

> I would have agreed if there was another use for the buttons.  But "if you
> don't like the button, just don't press it" sounds like right to me.  It's like
> the reset button on your machine.

That boils down to saying: don't make a typo. The reset button isn't sitting next to a button I hit twice a minute. I would love to never press 4/5 when I am about to paste something, but given it is the same physical button as 3, I find the don't-make-a-typo argument weak. And xmodmapping 4/5 away just because I don't want to make a typo seems a bit extreme.

Mind you the effect of the 3/4/5 typo here is more than your average typo. In bash, for instance, you just executed the wrong command intead of the one you pasted if you press btn3-btn4/5-enter instead of btn3-enter. That is hard to undo.



How about this potential workaround. One likely never pastes and scrolls within say 30ms of each other.

If the click sequence is 3 followed by 4/5 in the next 30ms, then the 4/5 is ignored. (This prevents scrolling away from the command you just pasted in bash).

If the click sequence is 4/5 followed by 3 in the next 30ms, then undo the effects of the previous 4/5 and ignore the 3. (This basically ignores a string of confused signals. If you meant to scroll and 3 was the typo, then the next 4/5 will pick up where scrolling left off. If you meant to paste and 4/5 was the typo, then at least you don't paste someplace random, and get to paste again at the same location next time you press 3.)

This only kicks in when a potential typo is detected, and doesn't affect normal operation.

 

(In reply to comment #14)
> (In reply to comment #13)
> > And the "application" here is vte, cause that's the code receiving and handling
> > scroll-wheel events.  The application running inside your terminal never gets
> > scroll-wheel events, and has no way to do so.
> 
> I know nothing about terminal emulation, but I am pretty sure that an
> application can get mouse clicks (e.g. double clicking on a link inside w3m
> inside xterm) correct? Are buttons 1/2 treated unlike 4/5?

They are.  The whole mouse thing is an xterm extension.  And following from man xterm to the ctlseqs.ms file I can read this:

"""
The low two bits of \*(Cb encode button information:
0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release.
"""

So, it only supports buttons 1, 2, 3.


> How about this potential workaround. One likely never pastes and scrolls within
> say 30ms of each other.
> 
> If the click sequence is 3 followed by 4/5 in the next 30ms, then the 4/5 is
> ignored. (This prevents scrolling away from the command you just pasted in
> bash).
> 
> If the click sequence is 4/5 followed by 3 in the next 30ms, then undo the
> effects of the previous 4/5 and ignore the 3. (This basically ignores a string
> of confused signals. If you meant to scroll and 3 was the typo, then the next
> 4/5 will pick up where scrolling left off. If you meant to paste and 4/5 was
> the typo, then at least you don't paste someplace random, and get to paste
> again at the same location next time you press 3.)
> 
> This only kicks in when a potential typo is detected, and doesn't affect normal
> operation.

This is basically debouncing, and better done in the xorg or kernel input layer.

(In reply to comment #15)
> This is basically debouncing, and better done in the xorg or kernel input
> layer.

Fair enough. Googling around, I find other people have the same problem in Firefox for instance: https://bugs.launchpad.net/firefox/+bug/187313/comments/14

I am not sure about this being better done in xorg/kernel though. I can see games needing simultaneous 3/4/5 clicks. 

Is it the GTK layer that has a concept of scroll vs. paste, or the GNOME layer?




Btw, regarding the other aspect of the discussion above --- how to correctly scroll --- how about extending that xterm extension to acknowledge the existence of the new mouse buttons? Faking keypresses for any fixed choice of key clearly works for some apps, and does something unexpected in other apps. Or how about allowing the user to configure what key is faked?

(In reply to comment #15)
> """
> The low two bits of \*(Cb encode button information:
> 0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release.
> """
> 
> So, it only supports buttons 1, 2, 3.


Actually, reading the xterm document (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html) it already defines how to handle the mouse-wheel in the same extension:

"""
Wheel mice may return buttons 4 and 5. Those buttons are represented by the same event codes as buttons 1 and 2 respectively, except that 64 is added to the event code. Release events for the wheel buttons are not reported.
"""

Good catch.  Not sure how many apps implement it.  Interesting would be to know if screen implements it (or for someone to go implement it!)

I'll wait for someone to do the research and cook a patch.  Chris, ChPe, feel free :P.

There's also the defined "scroll N lines" sequences:
CSI Ps S   Scroll up Ps lines (default = 1) (SU)
CSI Ps T   Scroll down Ps lines (default = 1) (SD)

We may want to use them if the app has not set Mouse Tracking mode, rather then CUU/CUD.

(In reply to comment #19)
> There's also the defined "scroll N lines" sequences:
> CSI Ps S   Scroll up Ps lines (default = 1) (SU)
> CSI Ps T   Scroll down Ps lines (default = 1) (SD)

Those are what the application sends to the terminal, not terminal sending to the application.  Right?

> We may want to use them if the app has not set Mouse Tracking mode, rather then
> CUU/CUD.

That's a good question, given that CSI Ps A and CSI Ps B are bidirectional, and it's all listed in the same section.  S and T definitely work from app->terminal, as it is what handles scrolling.

*** Bug 538195 has been marked as a duplicate of this bug. ***

Actually, vte already sends scroll events to the application if the app claims to know how to handle them.  I just did a ":set mouse=a" in vim and verified that.

So, back to square one.

Humm, maybe adding UI for this is fine after all.  Unless another solution pops up.  Christian?

Created attachment 122984 [details] [review]
vte patch to make this behavior configurable

Here is a patch against trunk vte to make this behavior configurable.  gnome-terminal patch to follow.

Created attachment 122985 [details] [review]
gnome-terminal patch to make this behavior configurable

Here is the patch against trunk gnome-terminal to make it configurable.

Created attachment 131444 [details] [review]
Python definition for set_alternate_screen_scroll

Heath's patch also needs a definition to expose alternate_screen_scroll to the python bindings.

As an FYI, Ubuntu is carrying both Heath Caldwell and Jordan Callicoat's patches to expose this configurable item in the coming Ubuntu 9.04 Jaunty release.

How about making the number of lines adjustable in the vte API?

Kees, I really appreciate if Ubuntu doesn't carry API in the vte_ namespace unless the API is upstreamed.  You can rename it to ubuntu_vte_* for example.  These kind of stuff cause headaches for upstream.  Thanks.

The problem with adjusting the number of lines is the same as it was at the beginning of this discussion - UPARROW scroll is very different than pagegescroll in too many applications.   Shell history, IRC client history, VIM in insert mode, when you run any of those inside screen in a VTE-powered window they break in unwanted and sometimes disastrous ways.    Gnome VTE is unusable for me without one of the patches in this thread, which is a real issue.

Ultimately, with any button beyond 3, we have the problem of applications having a different keyboard mapping for the same or similar behavior, and it only gets worse as the button number increases.    If we're on the main vte screen, by all means scroll it back ourselves.   The unfortunate problem is that on an alternate screen, anything sent by the newer mouse buttons is basically line noise.

All that said, the number of GNOME users who run old console programs under Screen is likely very small.

Dan, your comments are irrelevant since the API allows disabling this feature altogether.

We (vte developers) fully understand what this bug is about.  Can I ask users to not leave comments with no information please.

No new information I meant.

Hi...

I'm encountering this problem as well, but with a twist.  Let me describe the situation.

1. I'm running MacOSX SnowLeopard..
2. ... with Vmware Fusion 3.0.2
3. ... with Fedora 11 in a virtual machine
4. ... with a Mac SuperMouse
5. ... using gnome terminal
6. ... running vim
7. ... copying with the left mouse button
8. ... pasting with the middle button/scroll wheel

The problem is that the SuperMouse's scroll wheel is incredibly sensitive, and when I click on the scroll wheel, the chances of accidentally scrolling approaches 100%, resulting in pasted text in the wrong place almost every single time.  It's unusable.

Sorry, apparently I didn't read the entire bug history.  Apparently there's a configuration parameter now?  How do I access it in a GUI manner?

Thank you.

(In reply to comment #42)
> Sorry, apparently I didn't read the entire bug history.  Apparently there's a
> configuration parameter now?  How do I access it in a GUI manner?

It has not been fixed yet.  A fixed is proposed and being considered.

Hi Behdad,

I would like to encourage you to finally apply the patches
by Heath and Jordan.  This is an accessibility issue, for people
like me with clumsy fingers it is hard to paste without inadvertently
moving the scroll wheel.  To make matters worse, many netbooks
have a tiny touchpad where a small area on the right of the pad
is used as a scroll area.  It is extremely easy to inadvertently
touch the scroll area and send scroll events while typing or
while trying to move the mouse cursor.

I've read through all the comments here and in bug 538195,
and spent some time thinking about alternative solutions,
but my conclusion is that the existing patches are the
best solution.

BTW, it took me quite some time to find out that the issue
originates from vte.  In case it matters, I'm using xfce4-terminal.

I'll take a patch that allows configuring the number of synthetic keypresses (which can be 0 as well).

Created attachment 168832 [details] [review]
vte patch allowing to configure the number of keystrokes

Here is a vte patch created against current git (0.25.90-12-gc737262).
It includes a vteapp.c change for easy testing since I have
difficulties to get gnome-terminal to build on my distro.

Created attachment 169000 [details] [review]
updated gnome-termnal patch

gnome-terminal patch to go along the new vte patch;
this was created and tested against gnome-terminal
2.31.3 (e8c560b).  It applies almost cleanly to
current git head (2.31.90-14-gf28e434), but I could not
get this to build since gnome-terminal depends on
newest glib/gtk+ etc.

This part is wrong:

 
-	if (terminal->pvt->screen == &terminal->pvt->alternate_screen ||
-		terminal->pvt->normal_screen.scrolling_restricted) {
+	if (terminal->pvt->alternate_screen_scroll &&
+	    (terminal->pvt->screen == &terminal->pvt->alternate_screen ||
+	     terminal->pvt->normal_screen.scrolling_restricted)) {

Comment on attachment 169000 [details] [review]
updated gnome-termnal patch

Needs to be re-done once the gsettings port of g-t lands.

Comment on attachment 168832 [details] [review]
vte patch allowing to configure the number of keystrokes

Needs to be an object property on VteTerminal, too.

Created attachment 179846 [details] [review]
Add vte_terminal_set_synthetic_scroll() API

Changes from previous version:

- rename "alternate_screen_scroll" to "synthetic_scroll"
  (as suggested in email)
- add VteTerminal object property

Note the object property doc comments have a "Since: 0.27.5",
please fix that up as appropriate when applying.

If this patch is accepted I will update the matching
gnome-terminal patch.

Thanks Johannes for your continued effort.

ChPe, are you fine adding API for this in gnome-terminal?

If you think this pref is necessary, I'm not opposed to a profile pref for it in g-t. Adding UI for it though, not sure.

The vte patch looks ok, except it needs to read "Since: 0.30" (unless you want to squeeze it into 0.28 ?)

However it's too late for any additions to g-t for 3.0, and the first thing that will land in 3.1 is the gsetting port, so updating the g-t patch at this time is not useful.

Hm, Gnome 3 release is still two months away, but since
this bug is already three years old it can't hurt to
wait a few more months...

Anyway, if gnome-terminal support needs to wait, could the vte
patch be merged now?  There are other popular terminals based on vte,
e.g. xfce4-terminal or lxterminal.

Could you please apply the
"Add vte_terminal_set_synthetic_scroll() API"
vte patch?  I think it passed your review and
does not need further work.  If you wait until
after the Gnome 3.0 release it might take another
half year or so until the API is available in
distros so that xfce4-terminal could use it.
Please.

it seems that we have similar goals - see bug 643233

Please, note that it would be great to have scrolling possible with mouse wheel, shift+pageup/pagedown, shift+up/down and for selections using shift+held mouse button.

After reading this conversation and patches I believe that your approach is possible, but may not be sufficient for my needs.

You cannot work correctly with:
VTE terminal running screen with split windows and with some other screen inside one of them. When it has focus, you probably want to scroll contents of inside screen and let inner screen decide about ammount of scrolled lines.

I think that there should be created just one new simple rule for terminals:

If in alternate_screen mode and received mouse wheel events, shift+pageup/pagedown events, shift+up/down events, mouse selections using shift+held mouse button, emmit this event to inner terminal.

Probably new escape sequences needs to be introduced for these events.

Hi Tomas,

shift+key events have nothing to do with this bug.

Apps can already get the mouse scroll events in alternate screen,
try vim and :set mouse=a (and notice that vim does the right
thing with the mouse scroll events: it scrolls the view but
keeps the cursor position, while vte's emulation just sends
cursor events).

This bug is about the inability to disable the vte mouse scroll
emulation, which is an awful usability disaster e.g. for mutt.
(Obviously, vte alt screen mouse scroll emulation is disabled if the
app enables mouse reporting, but one cannot change all curses apps
just to avoid the vte issue.)

See console_codes(4) man page.

Hi Johannes,

thanks for nice explanation. Ok, mouse scroll events are handled correctly. That is good news for me. It seems that it has not much common with my problem. Now I'm not much sure what it sends to program running in alternate screen, but I hope it's just information that mouse scroll occured and not the number of lines to be scrolled. Sorry for the noise.

BTW, xterm 282 now implements this behaviour as well, via the new DEC 1007 control sequence. [See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683942]

This is fixed in 0.34 and 0.36 via bug 709060.

*** This bug has been marked as a duplicate of bug 709060 ***