oAuth not properly working on Android with firefox as default browser

[erkenberg]

When using Firefox as default browser on Android (instead of Chrome), the login via the custom tab works fine, but the redirect somehow seems to trigger Cordova to create a new Application/webview instead of being sent to/caught by the webview that triggered the oAuth login.

The redirect then seems to get lost and the user just ends up in the freshly created Cordova app again with the login seemingly not successful.

I reproduced the issue with the example plugin from the open pull request #24

Steps to reproduce:

• Set Chrome or Firefox as default browser on the phone
• Start the application
• click on Sign in with oAuth
• click the fake oAuth button
• With Chrome: -> redirected back to the webview, the UI says LOGGED IN and allows to "logout".
• With Firefox: -> a new webview is created, the UI is in its initial state allowing to Sign in with oAuth

The inspect tool also shows that for each login attempt with firefox as default browser a new webview is created:

With Chrome we always have the same webview, no matter how often we log in/out.

Honestly, from what I tested so far, I'm not sure what the exact issue here is and would guess that it's not really the fault of this plugin but an issue with the custom tab implementation of firefox. The login works, but the redirect from the custom tab creates the new webview instead of being handled by the one starting the oAuth process.

Any ideas what could be done to fix this behavior?

[dpogue]

I wonder if setting the AndroidLaunchMode preference in config.xml to something like singleTop or singleInstance would force the Android OS to route the intent to the existing application instead of launching another copy?

[erkenberg]

Good Idea, I'll test it tomorrow and let you know 👍

[erkenberg]

We already used singleTop (which allows multiple instances).
However, switching to singIeInstance actually fixed the issue, thanks for the pointer!

Also I noticed that while the login now works perfectly fine and we only have one Cordova Application, the firefox custom tabs now somehow seem to continue to live as applications in the background until manually closed after the return (Here I logged in and out multiple times, for each time such a "background" firefox instance stays open:

Going into one and logging in again redirects again to the app and logs me in. Still better than before but not yet perfect :)

I would speculate that Firefox somehow always creates a new instance for the custom Tab and if the Cordova application only allows a single instance this gets somehow detached and lives on on its own without properly closing (in contrast to Chrome which wasn't affected at all from the change and works just fine). But no idea 🤷

I'm not sure if it makes sense to somehow set this via the plugin (if possible), there might be cases where this is not wanted.
But maybe adding a hint/warning in the readme would be helpful, as singleTop is the Cordova default.

**edit: ** Correction: More browsers seem to stay open in the background after login, including chrome.
Stay open: Chrome, Firefox, Edge, Samsung Internet browser
Close: Opera (but just sometimes 😖 )

[erkenberg]

Just tested a bit further:

Setting customTabsIntent.intent.setFlags(FLAG_ACTIVITY_NEW_TASK); before sending the intent to start the custom tab in this plugin seems to have the same effect (even with launchMode still being singleTop).

I stumbled over this flag in the google example for oAuth with custom tabs

(The example this plugin is based on for Android is marked as deprecated and links to the repo where I found this example).

So I guess this could be an approach for a plugin based fix, but one would probably need to understand more deeply what exactly happens when setting this flag before, I just quickly tested it once I saw it in the google example. Just noting it here for reference, for now we can follow the singleInstance approach.

[erkenberg]

Ok, I think I figured out a working solution 😅

launchMode singleInstance forbids also all other activities started from our activity in its task, therefore the custom tabs run in their own tasks separate from our Cordova App.

Using singleTask instead also allows other activities (like the custom tab) to be part of our stack, so the custom tab is still started inside our application (which is not the case with singleInstance) on top of our Cordova activity, while still limiting our actual Cordova Application to one instance. Thus the login works fine on all browsers I tested and none of them stay open in the background (except for Opera, but I think they just don't offer custom tabs and therefore the login always just happens through the actual browser)

[dpogue]

So the Cordova default is singleTop.
Is the fix here for apps to use singleTask, or for us to add the FLAG_ACTIVITY_NEW_TASK? or both?

[erkenberg]

Ah sorry I guess my responses got a bit confusing as I just added my new discoveries as new comments 😅

In the end we only needed singleTask for the app, no change in the plugin (so no FLAG_ACTIVITY_NEW_TASK).

With singleTask the login is always started inside the app as overlay (except for default browsers that don't support custom tabs, there it just starts the regular browser). And when canceling or logging in, the overlay closes without leaving any pending custom tabs in the background, always resuming to our application.

In the Apps Cordova config.xml just add

  <preference name="AndroidLaunchMode" value="singleTask"/>