After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745315 - Overshoot deceleration causes WebKitGTK1 web view to jump back when scrolling
Overshoot deceleration causes WebKitGTK1 web view to jump back when scrolling
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkScrolledWindow
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-02-27 23:05 UTC by Sebastian Keller
Modified: 2015-09-14 17:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
video of the problem (392.21 KB, video/webm)
2015-02-27 23:05 UTC, Sebastian Keller
  Details
scrolledwindow: cancel overshoot when adjustment got changed (1.70 KB, patch)
2015-02-27 23:08 UTC, Sebastian Keller
reviewed Details | Review
scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events (1.23 KB, patch)
2015-03-02 16:03 UTC, Carlos Garnacho
committed Details | Review

Description Sebastian Keller 2015-02-27 23:05:32 UTC
Created attachment 298143 [details]
video of the problem

In a WebKitGTK1 (WebKitGTK2 doesn't use GtkScrolledWindow) web view, when scrolling up far enough to trigger the overshoot, immediately scroll down again while the overshoot indicator is still shown. The scrolled window now jumps back and forth between the window being scrolled fully up to the top and being slightly scrolled down until the overshoot disappears and scrolling works as expected again. A good program to test this with is liferea which still uses WebKitGTK1. Other widgets might be affected as well, but I've only seen this behavior in WebKit.

What I *think* is happening that both the scrolled window and the embedded web view try to modify the adjustment but with a slight delay and the kinetic scrolling used by the overshoot ignores the updated adjustment resetting it again to be scrolled fully to the top.

I'm attaching a patch that cancels the overshoot deceleration when the adjustment has been changed. This does not affect the case of the overshoot changing the unclamped adjustment, since this does not result in a change event for the actual adjustment because its value remains the same.

I have tested this patch with touchpad, trackpoint and mouse wheel based scrolling as well as GTK_TEST_TOUCHSCREEN, but I'm not familiar with touch based scrolling, so maybe I'm missing certain subtleties.
Comment 1 Sebastian Keller 2015-02-27 23:08:57 UTC
Created attachment 298144 [details] [review]
scrolledwindow: cancel overshoot when adjustment got changed
Comment 2 Carlos Garnacho 2015-03-02 16:00:49 UTC
Review of attachment 298144 [details] [review]:

::: gtk/gtkscrolledwindow.c
@@ -3323,3 @@
-  if (priv->drag_device || priv->deceleration_id)
-    return;
-

This is a good catch, although not as related to the fix in the end :). It would be great if you did this as a separate commit, "make ::edge-reached work on touch/kinetic scrolling" would be an accurate commit log, the first paragraph of this patch commit log still would apply there AFAICS.

@@ +3326,3 @@
     priv->unclamped_vadj_value = gtk_adjustment_get_value (adjustment);
+
+  gtk_scrolled_window_cancel_deceleration (scrolled_window);

I don't think this is the best place to do this though, doing this on GtkAdjustment::value-changed breaks kinetic scrolling on touch devices, as the kinetic animation attempts to update the adjustment and gets self-cancelled.

The cancel_deceleration() call in gtk_scrolled_window_scroll_event() has been usually the place where this happens. What seems to happen here is that the WebKitWebView widget is irregularly allowing or not the further propagation of scroll events, so the scrolled window can't get to handle it.

Given we already have a captured event handler in GtkScrolledWindow, I think that's a better place for this to happen, I'm attaching a patch along these lines, which would be compatible with the updated patch as I suggest.
Comment 3 Carlos Garnacho 2015-03-02 16:03:33 UTC
Created attachment 298326 [details] [review]
scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events

This ensures the animation is cancelled if the child widget happens to
GDK_EVENT_STOP scroll events.
Comment 4 Carlos Garnacho 2015-03-02 16:45:26 UTC
Attachment 298326 [details] pushed as 3ccfcf5 - scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events
Comment 5 Sebastian Keller 2015-09-06 19:19:10 UTC
This bug got reintroduced in https://git.gnome.org/browse/gtk+/commit/?id=8599f209c1a0c766429429275027284491ded7ac
Comment 6 Carlos Garnacho 2015-09-14 17:31:05 UTC
(In reply to Sebastian Keller from comment #5)
> This bug got reintroduced in
> https://git.gnome.org/browse/gtk+/commit/
> ?id=8599f209c1a0c766429429275027284491ded7ac

Right, this code does need to go in the captured_event_cb function for WebKit1 to behave properly, it should be reapplied (and almost applies as-is).
Comment 7 Carlos Garnacho 2015-09-14 17:32:45 UTC
Attachment 298326 [details] pushed as e1694a7 - scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events