[image_picker] Transparent pressing on iOS 26 (#173453) #10533

celvinren · 2025-11-28T23:45:00Z

Issue: On iOS, taps on the camera confirmation bar (“Use Photo” / “Retake”) were leaking through UIImagePickerController and dismissing underlying UI (e.g., bottom sheets) — a system touch-through regression reported on iOS 26 and some 18.x devices.

Same codebase, the following beharvious is on ios 18:
https://github.com/user-attachments/assets/c3989a40-e6fd-4e2c-9053-3b0accea6f46

The following behavious is on ios 26:
https://github.com/user-attachments/assets/71afd88f-39d7-4b4e-8faf-a736997604af

After comment out the line 525 (Navigator.of(context).pop();) to keep the dialog after taking image from camera, we could reproduce the issue in example.

From the video on ios 18, we can see the the dialog always there no matter we cancel, use photo or retake+cancel.

On ios 26, when we cancel, we can see the dialog is still there, but when we use photo or retake+cancel and then the camera screen dismiss animation finished, the dialog got dismissed. This behavious is different to ios 18 and this is because the tap pass through to flutter layout on outside of the dialog.

What I changed: In packages/image_picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m, when presenting the camera picker I now create a transparent, high-level UIWindow to absorb background touches and restore the previous key window once the picker finishes or is cancelled. This blocks taps pass through without altering Flutter-side UX.

Fixes: flutter/flutter#173453

Pre-Review Checklist

Issue: On iOS, taps on the camera confirmation bar (“Use Photo” / “Retake”) were leaking through UIImagePickerController and dismissing underlying UI (e.g., bottom sheets) — a system touch-through regression reported on iOS 26 and some 18.x devices. What I changed: In ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m, before presenting the camera picker I now create a transparent, high-level UIWindow to absorb touches and restore the previous key window once the picker finishes or is cancelled. This aims to block those leaked taps without changing Flutter-side UX.

flutter-dashboard · 2025-11-28T23:45:04Z

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

google-cla · 2025-11-28T23:45:05Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

gemini-code-assist

Code Review

This pull request fixes an issue on iOS where touch events could leak through the image picker and interact with the UI underneath. The solution is to introduce a temporary, transparent UIWindow that covers the screen and blocks these touches while the camera UI is active. The implementation is sound, but I've identified a potential crash scenario on iOS 13+ for apps that don't use scenes, and I've also suggested a small improvement for robustness in the cleanup logic. Overall, this is a good fix for the reported problem.

gemini-code-assist · 2025-11-28T23:46:31Z

...picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m

+  if (@available(iOS 13.0, *)) {
+    blockerWindow = [[UIWindow alloc] initWithWindowScene:presentingWindow.windowScene];
+  } else {
+    blockerWindow = [[UIWindow alloc] initWithFrame:presentingWindow.bounds];
+  }


On iOS 13 and later, presentingWindow.windowScene can be nil for applications that have not adopted a scene-based lifecycle. The -[UIWindow initWithWindowScene:] initializer will raise an exception if the provided scene is nil. To prevent a potential crash, you should add a check to ensure presentingWindow.windowScene is non-nil before calling this initializer.

Suggested change

if (@available(iOS 13.0, *)) {

blockerWindow = [[UIWindow alloc] initWithWindowScene:presentingWindow.windowScene];

} else {

blockerWindow = [[UIWindow alloc] initWithFrame:presentingWindow.bounds];

}

if (@available(iOS 13.0, *) && presentingWindow.windowScene) {

blockerWindow = [[UIWindow alloc] initWithWindowScene:presentingWindow.windowScene];

} else {

blockerWindow = [[UIWindow alloc] initWithFrame:presentingWindow.bounds];

}

gemini-code-assist · 2025-11-28T23:46:31Z

...picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m

+- (void)removeInteractionBlocker {
+  self.interactionBlockerWindow.hidden = YES;
+  if (self.previousKeyWindow) {
+    [self.previousKeyWindow makeKeyWindow];
+  }
+  self.interactionBlockerWindow = nil;
+  self.previousKeyWindow = nil;
+}


To improve robustness and make the code's intent clearer, it's good practice to add a guard clause at the beginning of removeInteractionBlocker to check if interactionBlockerWindow is non-nil. This prevents the rest of the method from executing unnecessarily if it's called when no blocker window is present.

- (void)removeInteractionBlocker { if (!self.interactionBlockerWindow) { return; } self.interactionBlockerWindow.hidden = YES; if (self.previousKeyWindow) { [self.previousKeyWindow makeKeyWindow]; } self.interactionBlockerWindow = nil; self.previousKeyWindow = nil; }

jmagman · 2025-12-02T00:26:30Z

@hellohuanlin can you take a look at this one since it's platform view gesture leaking? flutter/flutter#175099

hellohuanlin

Could you update PR description to include a video of the bug?

Also curious if you can override the hitTest method to block the touches. We had a similar issue on platform view and hitTest approach worked (See google.com/url?sa=t&rct=j&esrc=s&source=appssearch&uact=8&cd=0&cad=rja&q&sig2=z9f4fJu8gAZIeOOxYp5-Og&ved=0ahUKEwjA1YSnn_CQAxU6NPkAHbu-F4c4ABABKAAwAA&url=https://drive.google.com/a/google.com/open?id%3D1ag4drAdJsR7y-rQZkqJWc6tOQ4qCbflQSGyoxsSC6MM&usg=AOvVaw1gN-fgIfS1_BC13hGsvGi8)

hellohuanlin · 2025-12-02T22:27:36Z

packages/image_picker/image_picker_ios/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 0.8.13+3
+
+* Fixes camera confirmation taps leaking through the picker on some iOS versions (e.g., iOS 26).


It's unclear to me what "leaking" means? is it memory leak? or is it the tap gets passed through?

hellohuanlin · 2025-12-02T22:28:07Z

packages/image_picker/image_picker_ios/example/lib/main.dart

-                Navigator.of(context).pop();
+                // Leave the dialog open to verify that tapping the transparent area no longer pops it.
+                // Regression check for https://github.com/flutter/flutter/issues/173453.
+                // Navigator.of(context).pop();


To reproduce the issue, have to comment this line. Not sure we are going to remove it, so I comment it.

hellohuanlin · 2025-12-02T22:31:14Z

...picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m

-  [picker dismissViewControllerAnimated:YES completion:nil];
+  [picker dismissViewControllerAnimated:YES
+                             completion:^{
+                               [self removeInteractionBlocker];


hellohuanlin · 2025-12-02T22:31:35Z

...picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m

  self.callContext = nil;
 }

+- (void)addInteractionBlocker {


this needs some documentation on why we need it.

hellohuanlin · 2025-12-02T22:33:51Z

...picker/image_picker_ios/ios/image_picker_ios/Sources/image_picker_ios/FLTImagePickerPlugin.m

+    return;
+  }
+  self.previousKeyWindow = presentingWindow;
+  UIWindow *blockerWindow;


why do we need a window rather than just a view to block the touches

Hi, @hellohuanlin

We’re using a separate UIWindow instead of dropping a view in the Flutter hierarchy to make the touch blocker reliable:

Flutter’s UI lives in a UIWindow managed by FlutterViewController; UIImagePickerController is presented modally in that same window, layered above Flutter. When dismissing (e.g., Retake/Use Photo), the picker’s view is animating away, and stray taps can leak to the Flutter view underneath.

A view-based blocker (hitTest) would have to be inserted into the host view tree (e.g., FlutterViewController.view), inheriting its bounds/constraints/rotation and any transitions. During modal animations, size/position changes, or if the parent is re-laid out/replaced, the blocker can shift or get removed, letting touches through.

A dedicated UIWindow sits above the presenting window (windowLevel + 1), with its own root VC to swallow touches, and doesn’t depend on the host view hierarchy or transitions. We just restore the previous key window after dismiss, making it less invasive and more reliable for the short dismissal window.

The following 2 screenshots are using view and image picker will replace the flutter view controller. The first one shows we are in flutter view controller, the second one shows when we trigger the camera page from flutter, the flutter view become invisible and image picker takes place all the view.

The following is using a window for camera

In the first 2 hierarchy snapshots, the picker is full screen, so the Flutter view is temporarily out of the visible view tree. In the third snapshot, both the picker stack and FlutterViewController appear under the same key UIWindow, showing they share one window for event delivery. That’s why a blocker tied to the host view can shift or disappear during the modal transition, while a separate window stays put and reliably swallows taps.

Calvin Ren added 2 commits November 29, 2025 00:10

update changelog

8ad0a7f

celvinren requested review from LouiseHsu and vashworth as code owners November 28, 2025 23:45

github-actions bot added p: image_picker platform-ios labels Nov 28, 2025

gemini-code-assist bot reviewed Nov 28, 2025

View reviewed changes

modify from robot review

967e1d0

celvinren force-pushed the image_picker-transparent-pressing-on-iOS-26-#173453 branch from 5711bdd to 967e1d0 Compare November 29, 2025 00:10

celvinren marked this pull request as draft November 29, 2025 06:02

celvinren marked this pull request as ready for review November 29, 2025 06:03

jmagman requested a review from hellohuanlin December 2, 2025 00:25

stuartmorgan-g added the triage-ios Should be looked at in iOS triage label Dec 2, 2025

hellohuanlin reviewed Dec 2, 2025

View reviewed changes

celvinren requested a review from hellohuanlin December 3, 2025 13:21

		@@ -1,3 +1,7 @@
		## 0.8.13+3

		* Fixes camera confirmation taps leaking through the picker on some iOS versions (e.g., iOS 26).

[image_picker] Transparent pressing on iOS 26 (#173453) #10533

Are you sure you want to change the base?

[image_picker] Transparent pressing on iOS 26 (#173453) #10533

Conversation

celvinren commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pre-Review Checklist

Uh oh!

flutter-dashboard bot commented Nov 28, 2025

Uh oh!

google-cla bot commented Nov 28, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Nov 28, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Nov 28, 2025

Choose a reason for hiding this comment

Uh oh!

jmagman commented Dec 2, 2025

Uh oh!

hellohuanlin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

celvinren Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

celvinren commented Nov 28, 2025 •

edited

Loading

celvinren Dec 3, 2025 •

edited

Loading