[expo-web-browser] Browser closes when switching to a different app temporarily (Android)

[Rohansi]

🐛 Bug Report

Environment

  Expo CLI 3.19.2 environment info:
    System:
      OS: Windows 10 10.0.18362
    Binaries:
      Node: 10.16.3 - C:\Program Files\nodejs\node.EXE
      npm: 6.9.0 - C:\Program Files\nodejs\npm.CMD
    npmPackages:
      expo: ^37.0.7 => 37.0.7
      react: 16.9.0 => 16.9.0
      react-native: https://github.com/expo/react-native/archive/sdk-37.0.0.tar.gz => 0.61.4

Targeting Android and iOS using the managed workflow. Experiencing this problem on Android in both the client and standalone.

Steps to Reproduce

Start your login flow using AuthSession.startAsync and then continue it when it resolves successfully. If it's not successful then give the user an option to retry.

After starting the login flow the browser should open. Switch to another app and then switch back to the login screen.

Expected Behavior

The browser should stay open when returning to the app.

Actual Behavior

The browser closes and the user must restart their login process. This is a major issue for anything using two factor authentication because they will need to switch apps after entering their email and password, copy a code, and then paste it on the login page to continue.

Reproducible Demo

https://snack.expo.io/7wvmAi3cf

[byCedric]

Hi @Rohansi, thanks for your report and example! Unfortunately, this is the expected behavior from the new chrome custom tabs. But there is a way to prevent closing the chrome tab, you can use showInRecents. Could you try this and see if this works for you?

await WebBrowser.openAuthSessionAsync(
    'https://expo.io/', 
    'https://expo.io/', 
    { showInRecents: true },
);

Hope it helps!

[Rohansi]

Thank you @byCedric, but how do I set that from AuthSession.startAsync?

[byCedric]

Thank you @byCedric, but how do I set that from AuthSession.startAsync?

I'm so sorry! I thought I copied the snipper for auth-sesison, here it is:

AuthSession.startAsync({ showInRecents: true });

[cruzach]

Closing since this is expected behavior

[Rohansi]

@cruzach I don't really buy that there is no way around this. Chrome Custom Tabs are pretty much the standard and recommended way of authenticating with other services. Two factor authentication is also strongly recommended.

I haven't seen an app which leaves login pages in the app switcher, and I haven't seen any break when switching to get your two factor code, so what are they doing differently? Both of these options are bad UX - even if one of them is much better than the other.

[cruzach]

@Rohansi I'm a little confused- after adding showInRecents: true, what's the issue?

[Rohansi]

@cruzach It works fine but the login page sticks around in the app switcher. This will be confusing for users because there is no indication that it's for my app or that they are meant to just close it.

Additionally, if you press the back button after logging in you will return to the custom tab! I googled this problem and found that there does seem to be a solution to it but it looks quite convoluted. Android things, I guess.

Quite detailed documentation on the solution here: https://github.com/openid/AppAuth-Android/blob/f1dbeb51f4d905523d804d70363abdb00728d99c/library/java/net/openid/appauth/AuthorizationManagementActivity.java

Article I found explaining that it's a pain point for everyone: https://medium.com/@vardaansh1/use-chrome-custom-tabs-they-said-it-will-be-fun-they-said-b5fabe5daea3

It would be great if you could get this behavior working in Expo! I'm also stuck with OpenID 2.0 (the old one! - not OAuth or OpenID Connect) so I wouldn't benefit from the newer expo-auth-session APIs also.

[stale]

It's been a while since we've had any activity on this issue, and seeing as it needs more info before we can properly address it, we will be closing it in one month. If you've found a fix, please share it! Otherwise, please provide the info we asked for, especially a reproducible example. Thanks!

[stale]

It's been a while since we've had any activity on this issue, and seeing as it needs more info before we can properly address it, we will be closing it in one month. If you've found a fix, please share it! Otherwise, please provide the info we asked for, especially a reproducible example. Thanks!

[robinbiondi]

Hello, we have exactly the same issue here. The showInRecent fixes it but the form continues to be accessible by the user and the user can redo the operation again and again. This is not acceptable for our payment solution.
This behavior of closing the browser when app goes background isn't there on iOS. I don't understand why this behavior is expected on Android.
Regards,

[brentvatne]

@robinbiondi - @byCedric was saying this is expected behavior from the chrome custom tabs api, not that it is something that users would necessarily expect. sadly not every abstraction can work identically across platforms due to quirks in how they are implemented in different operating systems. if you think we are missing some aspect of the chrome custom tabs api that would make this possible without adding the showInRecents option, please let us know

[Rohansi]

@brentvatne I posted a solution above 😄

https://medium.com/@vardaansh1/use-chrome-custom-tabs-they-said-it-will-be-fun-they-said-b5fabe5daea3#c471

[brentvatne]

@Rohansi - open a pull request. if we're able to review and merge it by the end of next week we can possibly land it in sdk 41

[DPirate]

Hey, any update regarding the resolution within expo managed flow? Or possible alternatives? Thank you.

Here is an OAuth PR that may help - openid/AppAuth-Android#109

[stale]

It's been a while since we've had any activity on this issue, and seeing as it needs more info before we can properly address it, we will be closing it in one month. If you've found a fix, please share it! Otherwise, please provide the info we asked for, especially a reproducible example. Thanks!

[stale]

This issue has been automatically closed since there has not been any recent activity after it was marked as stale. Please open a new issue for any related bugs.

[Rohansi]

Boop again, not stale

[forki]

is there a good solutions now?

[github-actions]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[Rohansi]

@forki Not that I know of within Expo

[melanger]

I was facing the same problem, authentication did not work at all when using password manager (after switching back from the password manager, the authentication window was lost).

For me, the solution was to change this in my code:

 const [request, response, prompt] = useAuthRequest( /* ... */ );
 // ...
-prompt();
+prompt({ createTask: false });

[github-actions]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[Rohansi]

This is still an issue - not stale

[lechinoix]

Indeed using openBrowserAsync(url, { createTask: false }) gives me a behaviour pretty close to the one on iOS, thanks !

[github-actions]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[Rohansi]

Not stale

[dharmenbavaria]

We are also facing this issue especially when you have OAuth2.0 with Azure AD and you have MFA enabled. I tried with createTask: false and it helps as well but, if you don't use your authenticator within 10 seconds the browser popup is stuck and it doesn't redirect back so the user is stuck at the login screen. I would really appreciate it if anyone has any further solution for it.

[MarchewkaMatthew]

Hi everyone,

We have been using the { createTask: false } solution in our project until now. However, some of our Android users had problems with the results of the auth session. The app received a dismiss result type even if the login was successful. The issue is described here: #12044 in detail.

One of the proposed solutions that we've found here: https://stackoverflow.com/questions/66080607/expo-authsession-returns-dismiss-on-android-device is setting up createTask: true (together with showInRecents: true). Is there anyone who managed to close the Chrome auth tab after a successful login?

I have tried using the dismiss method imported from the expo-auth-session package, but it's breaking my auth flow - The app is coming back to the state from before the login, and after reloading the app user is logged in.

[JoezerSmaniotto]

When using {showInRecents: true} Chrome custom tabs, the window is not closed on redirection.

If you use { createTask: false }, the same thing happens and the chrome window overlaps the APP, having to click on the X in the window to close it. something that is not expected, but automatic closing.

[JPStrydom]

We have a similar issue on Android:

1. When a user is in an expo auth session browser session waiting for an OTP email, and
2. The user then navigates away from the app by minimizing it (swiping up on Android)
3. Then the user will experience an issue if they navigate back to the app in a certain way:
   1. If the user navigates back to the app by accessing it via their recent apps (swiping up and holding on Android), then the web session resumes correctly (i.e. where the user left off to enter their OTP)
   2. If a user navigates back to the app by clicking on the app icon, then the app resets to the root of the application (i.e. closes the web session)

Has anyone else experienced this? This might be caused by how we open our app (see the Android app lifecycle for more info), or this might be caused by expo auth session.

We're currently using Expo ^49.0.21 and Expo Auth Session ~5.0.2, and we're opening the auth session with { createTask: false }.

[MarchewkaMatthew]

Hi @JPStrydom, we are facing the same issue right now, did you figure out how to keep the auth session active when the user opens the app via the app icon?

[MarchewkaMatthew]

Hi @JPStrydom, I think I have found a piece of code that is causing the issue that we are facing. It's in the expo-web-browser package, inside of the AppState change listener.

Line added with this commit: e63f5cc#diff-01818e31c06fba75830f0a526c9dffbf17fb3d68ed18c9f0ba92d14191445114

When the user returns to the app using the app icon, the listener is triggered with the state "active" which triggers the browser to close. Does anyone have a solution for it? We would like to keep the user auth session until it's closed manually.

[adrianofoschi]

We have the same issue using WebauthN create function on some smartphones that open a new activity for fingerprint input.

#27908

[lsironic]

this worked for us on Android

const [request, response, promptAsync] = AuthSession.useAuthRequest(...
....
await promptAsync({ showInRecents: true, createTask: false });

"expo": "50.0.8"
"expo-auth-session": "5.4.0"
"expo-web-browser": "12.8.2"

[JoezerSmaniotto]

It only works on Android, on IOS it doesn't work at all!