Zum Inhalt springen
flutter 2026-03-06

Fix: Flutter WebView Tap-Gesten funktionieren nicht mehr nach Scrollen in NestedScrollView (iOS)

Ein bestätigter Flutter-Framework-Bug bricht alle Tap-Gesten auf WebViews innerhalb von NestedScrollView auf iOS. Die Lösung: Upgrade auf Flutter 3.38.6+.


Fix: Flutter WebView Tap-Gesten funktionieren nicht mehr nach Scrollen in NestedScrollView (iOS)

Fix: Flutter WebView Tap-Gesten funktionieren nicht mehr nach Scrollen in NestedScrollView (iOS)

TL;DR: Ein bestätigter Flutter-Framework-Bug (flutter/flutter#175099) sorgt dafür, dass alle Tap-Gesten auf WebViews innerhalb eines NestedScrollView nach der ersten Scroll-Interaktion auf iOS nicht mehr reagieren. Die Lösung: Flutter auf Version 3.38.6 oder neuer upgraden. Keine Code-Änderungen nötig.

Dieser Beitrag setzt Erfahrung mit Flutter, WebViews und der Komposition von Scroll-Widgets voraus. Wer mit platform views in Flutter noch nicht vertraut ist, sollte mit der offiziellen Platform Views Dokumentation starten.

Was ist dieser Bug?

Flutter WebView Tap-Gesture-Failure ist ein Bug auf Framework-Ebene, bei dem Tap-Events (Links, Buttons, Formularfelder) auf einem WebView Widget nicht mehr registriert werden, nachdem der User innerhalb eines NestedScrollView-Containers auf iOS gescrollt hat. Das WebView rendert korrekt und Scroll-Gesten funktionieren weiterhin, aber alle Tap- und Klick-Interaktionen reagieren nicht mehr.

Betroffen sind Apps, die webview_flutter oder flutter_inappwebview verwenden und das WebView in einem NestedScrollView, CustomScrollView oder einem anderen verschachtelten scrollbaren Layout platzieren.

Das Problem

Unsere App hat eine Seite mit Tabs, gebaut mit einem NestedScrollView, einer fixierten Tab-Bar und einem IndexedStack mit Tab-Inhalten im Body. Mehrere Tabs rendern Web-Content über flutter_inappwebview WebViews mit einer festen, berechneten Höhe:

body: NestedScrollView(
  headerSliverBuilder: (context, innerBoxIsScrolled) {
    return [
      SliverPersistentHeader(pinned: true, delegate: _HeaderDelegate(...)),
      SliverPersistentHeader(pinned: true, delegate: _TabBarDelegate(...)),
    ];
  },
  body: IndexedStack(
    index: tabController.index,
    children: [
      const NativeTabContent(),
      WebViewTabA(),  // WebView
      WebViewTabB(),  // WebView
      NativeTabC(),
    ],
  ),
),

Jeder WebView-Tab wickelt den Content in ein SingleChildScrollView mit einer SizedBox auf der gemessenen Content-Höhe, während vertikales Scrollen im WebView selbst deaktiviert ist — das NestedScrollView übernimmt das gesamte Scrolling:

SingleChildScrollView(
  child: SizedBox(
    height: contentHeight.value,
    child: webViewStack,
  ),
)

Das funktionierte einwandfrei — bis es das nicht mehr tat. Nach der ersten Scroll-Interaktion auf einem iOS-Gerät reagierte keine einzige Tap-Geste auf dem WebView mehr. Links, Buttons, Formularfelder — nichts wurde registriert. Das WebView renderte korrekt und Scrollen funktionierte weiterhin, aber alle Tap-/Klick-Events wurden stillschweigend geschluckt.

Ursachenanalyse

Die Grundursache ist eine fehlerhafte Interaktion zwischen Flutters Gesture-System und iOS platform views innerhalb verschachtelter Scroll-Container.

So läuft es Schritt für Schritt ab:

  1. Flutter rendert WebViews als platform views — native iOS UIView-Instanzen, die in den Flutter Layer Tree eingebettet sind.
  2. Wenn der User scrollt, beansprucht der NestedScrollView die Scroll-Geste über Flutters gesture arena.
  3. Flutter hatte zuvor einen Workaround für eine iOS 18.2 Gesture-Blocking-Regression ausgeliefert (flutter/flutter#158961).
  4. Dieser Workaround hat das Gesture-Blocking-System vollständig kaputt gemacht — für platform views innerhalb scrollbarer Container.
  5. Sobald der NestedScrollView die Scroll-Geste beansprucht hatte, wurde der Hit-Test-Bereich der platform view für Tap-Events nie korrekt wiederhergestellt.

Im Kern ist es ein Apple-seitiger Bug in der Handhabung von Gesture-Recognizer-Prioritäten bei platform views. Das Flutter-Team hat den ursprünglichen Workaround zurückgenommen und einen korrekten Fix in Stable 3.38.6 über PR #180522 ausgeliefert.

Die Lösung

Flutter auf Version 3.38.6 oder neuer upgraden:

# Mit FVM (Flutter Version Management)
fvm use 3.41.0  # oder jede Version >= 3.38.6

# Direkt mit Flutter
flutter upgrade

Keine Code-Änderungen nötig. Der Fix auf Framework-Ebene stellt die korrekte Gesture-Weiterleitung an platform views nach Scroll-Interaktionen wieder her.

Bin ich betroffen?

Dieser Bug betrifft dich wahrscheinlich, wenn alle folgenden Punkte zutreffen:

  • Du bettest ein oder mehrere WebViews (via webview_flutter oder flutter_inappwebview) in einen NestedScrollView, CustomScrollView oder ein anderes verschachteltes Scrollable ein
  • Tap-Gesten auf dem WebView funktionieren beim ersten Rendern, brechen aber nach dem Scrollen ab
  • Du verwendest eine Flutter-Version älter als 3.38.6
  • Das Problem tritt nur auf iOS auf (Android ist nicht betroffen)

Risiken beim Flutter-Upgrade

Ein Flutter-Upgrade mitten im Projekt birgt gewisse Risiken — Breaking Changes in anderen Bereichen, Plugin-Kompatibilitätsprobleme und Xcode-/Gradle-Versionsanforderungen. In unserem Fall verlief das Upgrade von 3.27 auf 3.41 problemlos, aber das kann bei dir anders aussehen. Version in .fvmrc pinnen und gründlich testen vor dem Release.

Häufig gestellte Fragen

Warum funktionieren WebView-Taps nach dem Scrollen in Flutter nicht mehr?

Ein Flutter-Framework-Bug sorgt dafür, dass das Gesture-Blocking-System für platform views (einschließlich WebViews) innerhalb verschachtelter Scroll-Container auf iOS versagt. Nachdem der Scroll View die Scroll-Geste beansprucht hat, werden Tap-Events auf der platform view nie wieder aktiviert. Upgrade auf Flutter 3.38.6+ behebt das.

Betrifft dieser Bug Android?

Nein. Es ist ein reines iOS-Problem, verursacht durch die Art, wie Apples UIKit Gesture-Recognizer-Prioritäten bei platform views handhabt.

Muss ich meinen Code ändern?

Nein. Der Fix liegt vollständig im Flutter-Framework. Upgrade auf Flutter 3.38.6 oder neuer behebt das Problem ohne jegliche Änderungen am App-Code.

Welche WebView-Packages sind betroffen?

Sowohl webview_flutter als auch flutter_inappwebview sind betroffen, da beide unter der Haube iOS platform views verwenden.

Weiterführende Links

KH
Khalit Hartmann Freelance Mobile & Full-Stack Developer