[webview_flutter][iOS] Platform view stops receiving touches after the first interaction on iOS 26 #191267

Steps to reproduce

Open a WebViewWidget on iOS 26 and interact with the page. The first touch is delivered normally; every touch after it is swallowed and the web view never receives another event for the rest of its lifetime.

I have not been able to reduce this to a minimal repro yet — the page that triggers it reliably for us is a third-party payment cashier whose form page embeds four cross-origin iframes and is taller than the viewport. Filing anyway because the measurements below point at a specific code path, and because the same failure reproduces with a second, independent webview plugin.

Expected results

Touches keep being delivered to the web view.

Actual results

After the first interaction the web view stops receiving touches entirely.

What I measured

I instrumented both sides to find where the touch is lost.

Flutter side — a Listener wrapping WebViewWidget logs every pointer event. It sees all of them:

FLUTTER-POINTER PointerDownEvent global=205,302 local=205,187
FLUTTER-POINTER PointerDownEvent global=291,288 local=291,173
FLUTTER-POINTER PointerDownEvent global=248,390 local=248,275

Listener defaults to HitTestBehavior.deferToChild, so the fact that it fires at all proves the platform view was hit.

Page side — a capture-phase listener on document logs touchstart / pointerdown / click. It receives nothing for any of the touches above. Injected JS run from Dart at the same coordinates confirms real, top-document elements are under the finger (not a cross-origin iframe, not an overlay):

PROBE-AT 205,187 stack=DIV.error.hide > DIV.input-item > FORM > DIV > DIV.pci-container
PROBE-AT 251,475 stack=DIV.billing-info-container > DIV.pay-fields-container > DIV.col-wrapper

The page is healthy — a setInterval heartbeat keeps firing, there are no JS errors, no failed requests, and onReceivedError / onReceivedHttpError stay silent.

The native scroll view is not receiving touches either — the document is scrollable (scrollHeight/clientHeight = 877/783) and drag gestures were performed, but window.scrollY never moved off 0. Scrolling needs no DOM events, so this rules out the page swallowing them.

The first interaction works. On the preceding page of the same web view (which happens to be exactly viewport height, 783/783) a tap produced the full sequence:

POINTERDOWN t=2569 ... TOUCHSTART ... TOUCHEND ... CLICK

Everything after that is dead.

Reproduces on

Also reproduces with flutter_inappwebview 6.1.5 on the same page. Both plugins register their platform view without specifying a policy, so both get the default eager.

Code that looks related

ForwardingGestureRecognizer.forceResetStateIfNeeded returns early on iOS 26 and above:

- (void)forceResetStateIfNeeded {
  // Apple fixed the bug where the gesture recognizer gets stuck at "failed" state in iOS 26.
  // The workaround is no longer needed on iOS 26+.
  // See: https://github.com/flutter/flutter/issues/179907
  if (@available(iOS 26.0, *)) {
    return;
  }
  ...
}

That safety net was removed based on a unit-test observation in #179907 (the recognizer reported .possible instead of .failed on iOS 26). The eager policy still installs the delaying recognizer, so if the recognizer does get stranded there is nothing left to recover it. The symptom matches the description in #136244 verbatim: "the gesture is not reset to 'possible' state and is stuck on 'failed' state, which causes subsequent touches to be blocked."

This is a hypothesis from reading the source, not something I instrumented natively — but it is consistent with every measurement above, and with the workaround below.

Workaround

Registering the platform view with FlutterPlatformViewGestureRecognizersBlockingPolicyDoNotBlockGesture fixes it completely on all three OS versions listed above. That policy does not install the delaying recognizer, so there is no recognizer state to strand; blocking still happens, via hitTest.

PR for webview_flutter_wkwebview: flutter/packages#12496

Flutter Doctor output

Flutter 3.47.0 • channel stable
Framework revision 4cf2416426 • 2026-08-11
Engine hash 59d54a2b2896a6bbf356c94b7fac7b9e235bdacd (revision 5f77625673)
webview_flutter 4.14.1
webview_flutter_wkwebview 3.26.0
Xcode / macOS 26.5.1