GNOME Bugzilla – Bug 745315
Overshoot deceleration causes WebKitGTK1 web view to jump back when scrolling
Last modified: 2015-09-14 17:32:49 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.
Created attachment 298144 [details] [review] scrolledwindow: cancel overshoot when adjustment got changed
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.
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.
Attachment 298326 [details] pushed as 3ccfcf5 - scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events
This bug got reintroduced in https://git.gnome.org/browse/gtk+/commit/?id=8599f209c1a0c766429429275027284491ded7ac
(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).
Attachment 298326 [details] pushed as e1694a7 - scrolledwindow: Cancel kinetic/overshoot animation on captured scroll events