[webview_flutter] Register the iOS platform view with the hit-test gesture blocking policy

[burakJs]

Registers the iOS platform view with FlutterPlatformViewGestureRecognizersBlockingPolicyDoNotBlockGesture instead of relying on the default eager policy.

eager blocks the platform view's gesture recognizers through Flutter's gesture arena, which is stateful. If that state is stranded the web view stops receiving touches for the rest of its lifetime. The engine used to recover from this in ForwardingGestureRecognizer.forceResetStateIfNeeded, but that reset returns early on iOS 26 and above (see flutter/flutter#179907), so on iOS 26 there is nothing left to recover it.

doNotBlockGesture derives the same blocking decision from hitTest rather than the arena, and does not install the delaying recognizer at all — so there is no recognizer state to strand. Blocking behaviour itself is preserved: FlutterTouchInterceptingView.hitTest still consults platformViewShouldAcceptTouchAtTouchBeganLocation: and returns itself when a Flutter widget is on top, and the forwarding recognizer is still installed so Flutter's arena keeps seeing the touches.

Verified on iOS 26.3 simulator, iOS 26.4 simulator and an iOS 26.6 device: the web view is unresponsive after the first interaction without this change, and behaves correctly with it.

Fixes flutter/flutter#191267

Open question for the reviewer: this change is unconditional rather than gated behind if #available(iOS 26.0, *). I went that way because it is not iOS-26-specific in principle — the arena state can be stranded on any version, iOS 26 just removed the net that used to hide it — and because it matches the direction described in flutter/flutter#175099 ("help prevent regressions even if this WebKit bug happens again"). Happy to add a version gate instead if you would rather keep the blast radius smaller.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under.
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request registers the iOS platform view with the hit-test based gesture blocking policy (FlutterPlatformViewGestureRecognizersBlockingPolicyDoNotBlockGesture) to prevent web views from becoming unresponsive to touches. It also adds a corresponding unit test and bumps the package version to 3.26.1. Feedback suggests using the more idiomatic Swift enum case .doNotBlockGesture instead of the verbose Objective-C name in both the plugin registration and the test file.

[gemini-code-assist]

In Swift, Objective-C enums are imported with shortened, idiomatic names. You can use .doNotBlockGesture instead of the verbose FlutterPlatformViewGestureRecognizersBlockingPolicyDoNotBlockGesture to make the code cleaner and more idiomatic.

      registrar.register(
        viewFactory, withId: "plugins.flutter.io/webview",
        gestureRecognizersBlockingPolicy: .doNotBlockGesture)

[burakJs]

.doNotBlockGesture does not compile here. The policy is declared in FlutterPlugin.h as a plain C enum:

typedef enum {
  FlutterPlatformViewGestureRecognizersBlockingPolicyEager,
  FlutterPlatformViewGestureRecognizersBlockingPolicyWaitUntilTouchesEnded,
  FlutterPlatformViewGestureRecognizersBlockingPolicyDoNotBlockGesture,
} FlutterPlatformViewGestureRecognizersBlockingPolicy;

Because it is not declared with NS_ENUM, the Swift importer does not shorten the case names. Building an app against Flutter 3.47.0 with the shortened form fails with:

Swift Compiler Error: Type 'FlutterPlatformViewGestureRecognizersBlockingPolicy' has no member 'doNotBlockGesture'

So the fully qualified constant is intentional. Happy to switch if the enum is ever annotated for Swift.

[hellohuanlin]

We should pass in the policy from the dart side instead: https://github.com/flutter/flutter/blob/f6061d0003a7a9e0cb30a45379c4c4bec0412c40/packages/flutter/lib/src/services/platform_views.dart#L1630

I'm glad that the new doNotBlockGesture policy works for you. However, this policy is designed as the last resort to deal with bugs of the platform view itself (e.g. WKWebView).

So it would be great if you can provide a reproducible project so we can look further.

[gemini-code-assist]

Using the idiomatic Swift enum case .doNotBlockGesture simplifies the assertion and improves readability.

      #expect(registrar.registeredGestureRecognizersBlockingPolicy == .doNotBlockGesture)

[burakJs]

Same reason as the other comment: the enum is declared as a plain C typedef enum rather than NS_ENUM, so the Swift importer keeps the full constant names and .doNotBlockGesture fails to compile.

[hellohuanlin]

We should pass in the policy from the dart side instead: https://github.com/flutter/flutter/blob/f6061d0003a7a9e0cb30a45379c4c4bec0412c40/packages/flutter/lib/src/services/platform_views.dart#L1630

I'm glad that the new doNotBlockGesture policy works for you. However, this policy is designed as the last resort to deal with bugs of the platform view itself (e.g. WKWebView).

So it would be great if you can provide a reproducible project so we can look further.