Skip to content

[google_sign_in_ios] Fix conflicting return type (BOOL vs void) in scene:openURLContexts: - #12777

Open
ledexsoft wants to merge 2 commits into
flutter:mainfrom
ledexsoft:fix/google_sign_in_ios-scene-openurlcontexts-return-type
Open

[google_sign_in_ios] Fix conflicting return type (BOOL vs void) in scene:openURLContexts:#12777
ledexsoft wants to merge 2 commits into
flutter:mainfrom
ledexsoft:fix/google_sign_in_ios-scene-openurlcontexts-return-type

Conversation

@ledexsoft

Copy link
Copy Markdown

Fixes a compile warning surfaced when building with Flutter 3.44.8 / Xcode 26 (iOS 26 SDK):

warning: Conflicting return type in implementation of 'scene:openURLContexts:': 'BOOL' vs 'void'

Cause

FLTGoogleSignInPlugin conforms to <FlutterSceneLifeCycleDelegate> and implements - (void)scene:openURLContexts:. In the Flutter iOS engine shipped with Flutter 3.44.8, FlutterSceneLifeCycleDelegate.h declares the method as:

- (BOOL)scene:(UIScene*)scene openURLContexts:(NSSet<UIOpenURLContext*>*)URLContexts;

(documented as "@return YES if this handled one or more of the URLs"), so the plugin's void implementation conflicts with the protocol's BOOL return type.

Fix

  • handleURLs: now returns BOOL (aggregating the FSIGIDSignIn handleURL: results with OR, mirroring the existing macOS handleOpenURLs: path).
  • scene:openURLContexts: now returns BOOL and propagates handleURLs:, matching the protocol and the existing application:openURL:options: pattern.

Verification

  • Checked every scene:openURLContexts: / handleURLs: occurrence in the package (only the plugin .m and the test-only header expose these; the existing Swift test handleURLs() still compiles since it ignores the return value).
  • Validated the new signature against the real FlutterSceneLifeCycleDelegate.h shipped with Flutter 3.44.8 via clang -fsyntax-only (exit 0).

Detected with Flutter 3.44.8 / Xcode 26 (iOS 26 SDK). Note: PR #12655 is migrating this plugin class to Swift; this change is complementary and scoped to the current Objective-C code.

@flutter-dashboard

Copy link
Copy Markdown

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

google-cla Bot commented Sep 7, 2026

Copy link
Copy Markdown

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 gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request modifies FLTGoogleSignInPlugin to return a BOOL from handleURLs: and scene:openURLContexts: to resolve a compilation warning. Feedback on the changes suggests replacing the logical OR assignment handled = [self.signIn handleURL:url] || handled; with an explicit if statement to avoid potential short-circuiting bugs if the expression is refactored in the future.

BOOL handled = NO;
for (NSURL *url in urls) {
[self.signIn handleURL:url];
handled = [self.signIn handleURL:url] || handled;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Relying on the left-hand side of the logical OR (||) operator to guarantee execution of a method with side-effects (handleURL:) is subtle and error-prone. If a future refactoring or automatic code formatter changes this to handled = handled || [self.signIn handleURL:url];, the short-circuiting behavior of || will prevent handleURL: from being called for subsequent URLs once handled becomes YES.

Using an explicit if statement is much safer, clearer, and less prone to accidental regression.

    if ([self.signIn handleURL:url]) {
      handled = YES;
    }

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied — replaced the short-circuit OR with an explicit if so the side-effecting handleURL: always runs regardless of prior results. Pushed in 5216498.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant