proyecto26 / react-native-inappbrowser

📱InAppBrowser for React Native (Android & iOS) 🤘
https://www.npmjs.com/package/react-native-inappbrowser-reborn
MIT License
1.32k stars 228 forks source link

Close inappbrowser on deeplink #312

Open BenjaminSAILcloud opened 2 years ago

BenjaminSAILcloud commented 2 years ago

Which platform(s) does your issue occur on?

Please, provide the following version numbers that your issue occurs with:

Hi,

I am using the inappbrowser to access a social website and I am NOT using it for authentication. In this website, there are buttons that links back to the app using deeplinks. I know they are working because when I access the website in browsers (e.g. Safari or Chrome) on the device, the deeplinks opens the app on the correct page. However when using the inappbrowser nothing happens.

How can I make the inappbrowser to handle correctly deeplinks without using the openAuth() method ?

Thanks

BenjaminSAILcloud commented 2 years ago

Hi,

Uppon more investigation, I found out that the deeplinks work correctly (e.g. they open the correct screen using react navigation) however when clicking the deeplink, the inappbrowser modal does not close...

andriiDatsiuk commented 2 years ago

@BenjaminSAILcloud take a look at a console of the page that should redirect user back to the app, probably you will see something like this: "Navigation is blocked: ...". I'm facing this issue as well. Here's what I've found so far.

https://bugs.chromium.org/p/chromium/issues/detail?id=738724 https://www.py4u.net/discuss/629990

The issue breaks auth flows with some 3rd party in my case. Users are not redirected back to the app after authentication.

jdnichollsc commented 2 years ago

Hello folks, please share a reproducible demo project to be able to debug your issue 👍

sgtpsibin commented 2 years ago

@jdnichollsc Have you ever tried to make complete example of using openAuth(). I read alot but everyone say that we can not redirect to a deep link to close inappbrowser. (including server-side redirection) Do you have any example of redirect url can redirect to a deeplink or trigger universal link as well?

mongkuen commented 2 years ago

Hello folks, please share a reproducible demo project to be able to debug your issue 👍

Appreciate the attention

Issue reproduced here: https://github.com/mongkuen/RNInAppBrowser-deeplink-demo

Video of issue https://www.loom.com/share/26355f2b3c874c50960055275637041a

TheWirv commented 2 years ago

I second this. We have payment integration via InAppBrowser and have been using openAuth up until now, but that always triggers the OS dialog, "{App name} Wants to Use {payment provider URL} to Sign In", which is really annoying, and confusing to end users. I have tried just replacing the openAuth with open, but after that the redirect after successful payment just simply doesn't work anymore. E.g. PayPal is just "processing" forever, whereas before it redirected back to the app afterwards. I have tried this comment, but that also does not work for me at all somehow. I tried putting a console.log inside the event listener, but nothing appears.

@jdnichollsc Is there a reason why the redirection logic has only been implemented for openAuth?

Oh, and on Android everything works fine. The Custom Tabs knows how to redirect out of the box.

mongkuen commented 2 years ago

This is probably a SFSafariViewController concern only.

Not an iOS/Objective C dev, and this solution is in swift, but I imagine this approach here might be close to the desired behavior?

Then maybe a documentation section on how to modify AppDelegate.m/AppDelegate.h to support view dismissal?

Thank you whoever is taking a look at this, it's very much appreciated :)

TheWirv commented 2 years ago

Yeah, something's up here. The SFSafariViewController just won't redirect. I have tested whether our API's redirection mechanism maybe wasn't working correctly by opening the payment process in Safari via the bottom right button that SFSafariViewController provides. After payment was successful, Safari without any problem redirects to the app, or at least it asks whether to "open the URL in the app". But inside of SFSafariViewController there's just nothing happening.

jdnichollsc commented 2 years ago

I second this. We have payment integration via InAppBrowser and have been using openAuth up until now, but that always triggers the OS dialog, "{App name} Wants to Use {payment provider URL} to Sign In", which is really annoying, and confusing to end users. I have tried just replacing the openAuth with open, but after that the redirect after successful payment just simply doesn't work anymore. E.g. PayPal is just "processing" forever, whereas before it redirected back to the app afterwards. I have tried this comment, but that also does not work for me at all somehow. I tried putting a console.log inside the event listener, but nothing appears.

@jdnichollsc Is there a reason why the redirection logic has only been implemented for openAuth?

Oh, and on Android everything works fine. The Custom Tabs knows how to redirect out of the box.

We're using the same strategy of WebBrowser (Expo), please check here for more details

alexisloiselle commented 2 years ago

Hey @TheWirv, I wanted to let you know that I got the comment you referenced to work by adding this to the AppDelegate.swift:

  func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    return RCTLinkingManager.application(app, open: url, options: options)
  }

Hope it helps!

focux commented 1 year ago

FYI, if you just want to close the in-app browser after handling a deep link, you just need to do:

InAppBrowser.close()

In your Linking.addEventListener callback.

JJbings commented 1 year ago

FYI, if you just want to close the in-app browser after handling a deep link, you just need to do:

InAppBrowser.close()

In your Linking.addEventListener callback.

This does not seem to work for me as the callback is executed after the browser is closed.

(OnAndroid) When pressing the menu --> "Open in Chrome" then the redirect is handled properly and redirects to the APP