Bug 197168 - [GTK] Back/Forward gesture interferes with scrolling
Summary: [GTK] Back/Forward gesture interferes with scrolling
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-22 10:55 PDT by raffaele.tranquillini
Modified: 2019-04-25 09:59 PDT (History)
4 users (show)

See Also:


Attachments
Screencast (3.55 MB, video/webm)
2019-04-22 10:55 PDT, raffaele.tranquillini
no flags Details
Patch (3.14 KB, patch)
2019-04-23 02:29 PDT, Alexander Mikhaylenko
no flags Details | Formatted Diff | Diff
Patch (3.04 KB, patch)
2019-04-23 03:50 PDT, Alexander Mikhaylenko
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description raffaele.tranquillini 2019-04-22 10:55:15 PDT
Created attachment 367951 [details]
Screencast

When I begin performing the Back gesture, then cancel it (by stopping dragging) and, before the slide animation (returning to the "normal status") is over, i start scrolling vertically, scrolling is sometimes disabled until i perform and cancel another "back/forward" gesture.

Not very visible in the attached screencast, but hope it helps
Comment 1 Alexander Mikhaylenko 2019-04-22 11:03:22 PDT
Interesting. I can reproduce it, though it's tricky.

It "fixes itself" after cursor movement, not necessarily until you start a new gesture. Still weird, because the snapshot is not shown during that time, so the gesture is not running...
Comment 2 Alexander Mikhaylenko 2019-04-23 00:34:07 PDT
So, what happens is that it's trying to animate the page, but the remaining distance is so small it looks like nothing is happening. And during that time you cannot scroll because you would restart the gesture if you do.

Seems we just need to be better at calculating animation duration when velocity is 0, i.e. when you just release the gesture. Currently in that case, the duration is always 400ms without considering the distance. We need something that is proportional to distance.
Comment 3 Alexander Mikhaylenko 2019-04-23 02:29:25 PDT
Created attachment 368021 [details]
Patch
Comment 4 Alexander Mikhaylenko 2019-04-23 02:31:02 PDT
This is a bit preliminary patch, I want to check with Tobias wrt the duration, though it feels good to me.

Note this doesn't 100% prevent this, but makes it a lot harder to reproduce (you need to scroll 4 times as fast). I can make it so that the minimum duration is 0 (as it was in the first iteration of the change), but it feels a bit weird when the page immediately snaps back when it's close to end point.
Comment 5 Alexander Mikhaylenko 2019-04-23 03:50:04 PDT
Created attachment 368022 [details]
Patch
Comment 6 Alexander Mikhaylenko 2019-04-23 03:53:36 PDT
Tobias liked the duration, and I forgot a few obsolete lines in the patch, so reuploading.

raffaele.tranquillini@gmail.com: can you still reproduce it with the patch? I can do a Epiphany build if you need to.
Comment 7 raffaele.tranquillini 2019-04-23 04:57:46 PDT
If you could make an Epiphany build with it, it would be great.
Comment 8 Alexander Mikhaylenko 2019-04-23 09:05:55 PDT
raffaele.tranquillini@gmail.com: https://gitlab.gnome.org/exalm/epiphany-gestures/blob/master/org.gnome.Epiphany.flatpak

I realized I should have built technology preview instead of stable already after having started building this one. However, since there's no "official" stable flatpak atm, should be fine.

Also, note this is very latest webkit, and there are some other breakages (for instance, snapshot always takes a long time to disappear after you complete the gesture, I already know the reason, but it's a different problem), so I'm only asking about this bug. :)
Comment 9 raffaele.tranquillini 2019-04-24 01:41:05 PDT
This seems to solve the particular test case I mentioned initially. However, it also seems to cause a regression, blocking a "forward" gesture immediately after a "back" one or vice versa.
Comment 10 raffaele.tranquillini 2019-04-24 01:42:43 PDT
This, by the way, happens only if I wait for the gesture animation to be completed before going the opposite direction. If I "cancel" it or start performing the opposite gesture before the animation is over, it seems to work propelry.
Comment 11 Alexander Mikhaylenko 2019-04-24 02:16:28 PDT
This isn't caused by the patch, and that breakage is the very reason I mentioned:

> Also, note this is very latest webkit, and there are some other breakages (for instance, snapshot always takes a long time to disappear after you complete the gesture, I already know the reason, but it's a different problem), so I'm only asking about this bug. :)

More specifically, I think it's caused by https://trac.webkit.org/changeset/243094/webkit. I tried to bisect it, but that commit also introduced a crash in webkitgtk, so I cannot know for sure. And I've almost fixed it locally.

The only thing the patch does is make the page snap back faster when you're cancelling it and it's close to edge. If you cannot reproduce the bug anymore, then it works :p
Comment 12 raffaele.tranquillini 2019-04-24 06:47:49 PDT
Sure, this particular bug isn't verified here (or not that often) and the speed is still absolutely acceptable.
Comment 13 Alexander Mikhaylenko 2019-04-24 08:22:14 PDT
raffaele.tranquillini@gmail.com: see https://bugs.webkit.org/show_bug.cgi?id=197233 for the timeout issue.
Comment 14 WebKit Commit Bot 2019-04-25 09:59:09 PDT
Comment on attachment 368022 [details]
Patch

Clearing flags on attachment: 368022

Committed r244649: <https://trac.webkit.org/changeset/244649>
Comment 15 WebKit Commit Bot 2019-04-25 09:59:11 PDT
All reviewed patches have been landed.  Closing bug.