GNOME Bugzilla – Bug 773578
The first scroll event gets swallowed
Last modified: 2016-10-28 07:11:26 UTC
This is reproducible in vte-2.91 and apps based on it (gnome-terminal, xfce4-terminal). Not reproducible in old (gtk2) vte. How to reproduce: - run the app and make it show some scrollable contents (e.g. run 'ls -l' or open a file in vim); - click desktop and then the app window (i.e. make the window lose focus and then regain it); - scroll the contents once - nothing will happen. The second scroll will work. This happens each time after the window has lost and regained focus.
How do you scroll? Do you use the mouse whell? (If so, I need to buy a mouse to reproduce/debug/fix it :) or figure out how to synthesize such events.) Shift+PgUp does work, right? I use a touchpad and the two-finger scroll works fine (although you can't define the concept of "first" scroll here). I guess it could be related to smooth scrolling, maybe a floating point cumulative error, like vte's asked to scroll by 0.9999 instead of 1.0.
(By "smooth scrolling" I meant GDK_SMOOTH_SCROLL / bug 710426 / commit 7efb04f, and not the sub-cell scrolling.)
Yeah, sorry for not mentioning it - the issue seems to only happen when using a mouse for scrolling; keyboard scrolling (with Shift+PgUp/PgDn or Shift+Ctrl+arrows) works fine.
Could you please run with a debug build of vte and VTE_DEBUG=events and paste the output?
(In reply to Egmont Koblinger from comment #4) > Could you please run with a debug build of vte and VTE_DEBUG=events and > paste the output? Guess I need some help here. I've build a debug version with `./configure --enable-debug` but how do I set VTE_DEBUG=events?
Okay, I somehow made it work. This is what gets printed when focusing the window and scrolling it with a mouse: Smooth scroll by 0.000000, delta now at 0.000000 Scroll speed is 3 lines per non-smooth scroll unit Smooth scroll by -1.000000, delta now at -1.000000 Scroll speed is 3 lines per non-smooth scroll unit
Just FYI you don't even have to install vte, you can run the test app: ./configure --enable-debug make VTE_DEBUG=events ./src/vte-2.91 I'll take a closer look later today. Until then, could you please also try with vte 0.42 (which does not yet have the per-pixel subcell super smooth scrolling)?
I had to set LD_LIBRARY_PATH to use the library that I've built instead of the system one. Version 0.42 produces the same result: the first scroll does not work: Smooth scroll by 0.000000, delta now at 0.000000 Scroll speed is 1 lines per non-smooth scroll unit Smooth scroll by -1.000000, delta now at -1.000000 Scroll speed is 1 lines per non-smooth scroll unit Scroll by -1 lines, smooth scroll delta set back to 0.000000
Could you please clarify what is what in the output? You say 0.42 produces the same, and then it's 5 lines, whereas in comment 6 it was 4 lines only. Did you simply accidentally omit the last line? Are the first two lines generated on the first scroll attempt, and then the next 3 lines on the second (which actually scrolls)? It seems we get an event from Gtk+ that is about scrolling by 0.0, there's nothing we could do in that case, sounds like perhaps a Gtk+ or X bug if an actual mouse wheel scroll is reported to us as such. I really don't feel like buying a mouse, so I tried the following command instead (making sure that the mouse is above vte): ls -l sleep 5; xdotool click 4; sleep 5 and it works for me as expected; does it work for you? Could you please try a few other gtk3 apps (e.g. gedit) and see if the same bug occurs for you there as well? What's your Gtk+ version?
See https://bugs.kde.org/show_bug.cgi?id=348270, esp. comments 23-31.
Yes, the "Smooth scroll by 0.000000, delta now at 0.000000" and the line after it indicates no scroll happening, and seeing "... by -1.000000" means there's scroll. I can confirm that gtk3 gedit is suffering from this bug, too; while gtk2 apps are respecting the 1st scroll event. My gtk version is 3.22.2. Thanks for the link! It shows an interesting story, and I believe this is indeed an upstream bug. Thank you for your time!
You're welcome :) Marking as dup. *** This bug has been marked as a duplicate of bug 750994 ***