Regression: gesture priority between PageView and WebView

[ludwiktrammer]

I have a vertically scrolling WebView inside a horizontally scrolling PageView. Something like this:

PageView.builder(
  itemCount: 5,
  itemBuilder: (context, index) {
    return WebView(
      initialUrl: 'https://flutter.dev/docs',
      gestureRecognizers: [
        Factory(() => VerticalDragGestureRecognizer()),
      ].toSet(),
    );
  },
);

With the previous stable version of Flutter (1.5.4), this worked as expected - scrolling vertically would move the content inside the WebView and scrolling horizontally would move the PageView.

This broke after upgrading to Flutter v1.7.8+hotfix.3. Now horizontal scrolling seems always to win, even if the gesture is very clearly almost entirely vertical. If the page gets scrolled vertically at all, it is only after the gesture stops (i.e., when I stop touching the screen after a gesture) - there is no vertical scrolling while the gesture is happening.

Adding and removing VerticalDragGestureRecognizer from gestureRecognizers have no effect now - either way the program works as if the recognizer was not on the list (although it's not that gestureRecognizers are completely ignored because adding EagerGestureRecognizer DOES have an effect).

Steps to Reproduce

1. Add the snippet above to a mobile app.
2. Try scrolling the page down in Flutter 1.5.4.
3. Try scrolling the page down in Flutter 1.7.8

Logs

Here is the debug output of the gesture arena (keep in mind that I was trying to keep my gesture as vertical as possible, but even a slight finger movement to the sides was enough for the HorizontalDragGestureRecognizer to win, even though I also was moving vertically the entire time):

I/flutter (30125): Gesture arena 14   ❙ ★ Opening new gesture arena.
I/flutter (30125): Gesture arena 14   ❙ Adding: Instance of '_CombiningGestureArenaMember'
I/flutter (30125): Gesture arena 14   ❙ Adding: LongPressGestureRecognizer#9cad1(debugOwner: GestureDetector, state: ready)
I/flutter (30125): Gesture arena 14   ❙ Adding: HorizontalDragGestureRecognizer#69b8f(start behavior: start)
I/flutter (30125): Gesture arena 14   ❙ Closing with 3 members.
I/flutter (30125): Gesture arena 14   ❙ Rejecting: LongPressGestureRecognizer#9cad1(debugOwner: GestureDetector, state: possible)
I/flutter (30125): Gesture arena 14   ❙ Accepting: HorizontalDragGestureRecognizer#69b8f(start behavior: start)
I/flutter (30125): Gesture arena 14   ❙ Self-declared winner: HorizontalDragGestureRecognizer#69b8f(start behavior: start)

flutter analyze output:

No issues found! (ran in 6.9s)

flutter doctor -v output:

[✓] Flutter (Channel stable, v1.7.8+hotfix.3, on Mac OS X 10.14.5 18F132, locale en-PL)
    • Flutter version 1.7.8+hotfix.3 at /usr/local/share/flutter
    • Framework revision b712a172f9 (7 days ago), 2019-07-09 13:14:38 -0700
    • Engine revision 54ad777fd2
    • Dart version 2.4.0


[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/ludwik/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Users/ludwik/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.2.1, Build version 10E1001
    • CocoaPods version 1.6.1

[✓] iOS tools - develop for iOS devices
    • ios-deploy 1.9.4

[✓] Android Studio (version 3.4)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 37.0.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[✓] Connected device (3 available)
    • Pixel                     • FA6AK0303775                         • android-arm64 • Android 9 (API 28)
    • Android SDK built for x86 • emulator-5554                        • android-x86   • Android 9 (API 28) (emulator)
    • iPhone 6                  • F2E9535A-2928-46BF-9872-1176E558D352 • ios           • com.apple.CoreSimulator.SimRuntime.iOS-10-0
      (simulator)

• No issues found!

[ludwiktrammer]

It may or may not be related to #35394.

[ludwiktrammer]

And this is what happens when you do manage to keep your gesture almost entirely vertical (seems to be easier on an emulator with a mouse), while the drag gesture is in process:

flutter: Gesture arena 30   ❙ ★ Opening new gesture arena.
flutter: Gesture arena 30   ❙ Adding: Instance of '_CombiningGestureArenaMember'
flutter: Gesture arena 30   ❙ Adding: HorizontalDragGestureRecognizer#11e7f(start behavior: down)
flutter: Gesture arena 30   ❙ Closing with 2 members.

Even a slight vertical move will make the HorizontalDragGestureRecognizer announce a win, but the VerticalDragGestureRecognizer (which seemsed to be wrapped inside the _CombiningGestureArenaMember) never claims a victory. It seems to be completely ignored in fact - the gesture arena output with VerticalDragGestureRecognizer in gestureRecognizers and without it is absolutely identical.

[ludwiktrammer]

There is now a workaround available here: https://stackoverflow.com/a/57150906/262618

The workaround involves creating a custom version of VerticalDragGestureRecognizer, as it seems that the build-in one doesn't work with platform views since Flutter 1.7.

[QingyangLiu]

This bug seems to be still present with the latest version. Not sure if they’ll ever fix this.

[ludwiktrammer]

@QingyangLiu This ticket has a "December 2019" milestone, so I guess that the current plan is to deal with this by then.

[FarmaanElahi]

Webview has serious scrolling issue when used inside PageView or any scrollable container in IOS devices
Check #40666

[ludwiktrammer]

I'm closing the issue because I'm now convinced that it's a duplicate of #35394.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.