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

[celvinren]

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 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 leaked taps without altering Flutter-side UX.

Fixes: flutter/flutter#173453

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• 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 updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].
• I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• All existing and new tests are passing.

[flutter-dashboard]

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]

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]

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]

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;
}