GNOME Bugzilla – Bug 739944
scrolledwindow bounds highlight stays lit under spurious scrolling
Last modified: 2018-04-15 00:39:19 UTC
Try two finger scrolling in a textview inside of a scrolled window. make sure there are enough lines for the textview to be able to scroll. now two finger scroll to the bounds. you should see the guard highlight animate at the edges (3.15.x) in light blue. now spuriously two finger scroll so that kinetic scrolling kicks in. you'll see the bounds guard stay completely lit.
This is due to the synaptics driver handling kinetic scrolling itself, it keeps sending scroll events which clients can't distinguish from real ones. On libinput/wayland, there are patches in the works that would make possible implementing kinetic scrolling on clients, which is a more desirable situation for GTK+. On X11/synaptics, a similar approach might be taken, sending a 0-distance last scroll event. But this should be something opted in in the gnome session, and the feature would be gone on non-GTK+ clients. In the mean time, maybe we can have the gradient retreat after a timeout when the edge is hit, regardless of further scroll events still arriving. This could make this flaw less evident.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new