Redirect while app in background with Chrome custom tabs

[dhei]

I am playing with the demo app using Chrome custom tabs (Chrome 55) vs. different browsers on an Android 6.0.1 device. I have configure the demo app to make it work properly. I also want to understand the common failures during user login using Chrome custom tabs compared to other browsers.

So I try to put the app into background after entering username & password but before redirect to custom scheme, to see if redirecting still works (RedirectUriReceiverActivity gets called). What I found it’s quite confusing - after Chrome custom tabs sent to the background, redirect never happen. Same behavior for a Chrome browser. Looks like this is not a Chrome custom tabs specific behavior, but to Chrome itself. I tried this scenario on Firefox browser (latest version) and Opera browser (latest version), redirect works fine even app in the background and RedirectUriReceiverActivity get called.

My question is why redirect not working when app in the background for Chrome custom tabs? Is this by design? If it is by design, are there any workarounds?

Thanks

[iainmcgin]

This sounds like it may be a Chrome bug, but I'd like to clarify the steps you are taking so I can report it. It sounds like the steps are you are taking are:

1. Start the authorization flow from the demo app, which opens a Chrome Custom Tab / Chrome browser.
2. Enter the authentication details into the tab, but do not submit them.
3. Switch to another app / the device home screen.
4. Switch back to the custom tab / browser, and submit the authentication details.
5. At this point, you expect that the redirect should be captured and processed by the app, but this does not happen.

Is this accurate? If so, what does happen at step 5 - does the browser / tab navigate directly to some other page, show an error, or appear to do nothing?

Could you provide the exact version of Chrome (e.g. 55.0.2883.95) and the Android OS version (e.g. 7.1) on the device you are testing with?

[dhei]

@iainmcgin, thanks for your response.

Here are the steps to repro with Chrome 55.0.2883.91 on Android 6.0.1:

1. Start the authorization flow from the demo app, which opens a Chrome Custom Tab.
2. Enter username and password into the tab and click ‘Sign in’
3. In the ‘AppAuth Demo would like to’ permission page, click ‘Allow’
4. Immediately switch the app to the background before redirect kicks in. Wait a few seconds. I expect redirect should happen at this point and switch me from background to the app. But nothing happens.
5. Switch back to the app, I see the original start page of the demo app, my auth flow is lost.

Note: Step 5 using Firefox/Opera does give me the expected behavior - redirect to the app when the app is in the background.

Thanks.

[dhei]

@iainmcgin, I was wondering if you have a chance to repro this issue? Thanks.

[iainmcgin]

Sorry, I've been out for a few weeks as I recently got married. I'm back now, and I'll try and repro this week.

[cjolif]

@iainmcgin congratulations :) Any news? (we do have the same issue as @dhei)

[iainmcgin]

I suspect it might be a Chrome issue - I wouldn't expect the redirect to happen in the background as the browser tab should be "frozen" when not visible. However, it should pick up from where it left off when you switch back, so some state must be being lost when switching out and back in.

Is this occurring in a common scenario, or are you just testing for robustness? I'll flag this to the Chrome Custom Tab engineers to see if they have an explanation.

[cjolif]

Nothing special, we just get that without doing anything special.

[SanjeevKumarPandey]

Is it too late to ask here? Wondering what exactly it means - '..browser tab should be "frozen" when not visible'? Is this a Custom Tabs behavior i.e. the redirect wouldn't happen if its in the background OR more in other sense 'user will always see the redirect happening, it can't be hidden'?

[contextsw]

@iainmcgin
We are almost 4 years into this issue has there been a resolution as it is becoming a blocker. The AWS Cognito has been resolved can't we borrow their solution?

[verejoel]

Are there any updates on this issue?