WebView Browser stays open after successful call to FlutterWebAuth2.authenticate Android

[BBQRIBS72]

Describe the bug

This is the same report as this bug on flutter_web_auth: LinusU#133
It also exists on this package, so I thought I would report it here

On android, if you successfully authenticate with FlutterWebAuth2.authenticate, when you are redirected back to the app, the browser tab used to authenticate you is still open in the app switcher. This tab is no longer needed so I think it should be closed?

To Reproduce

Steps to reproduce the behaviour:

1. Successfully authenticate on an android device
2. Go to app switcher
3. See that browser tab is still open

Expected behaviour

I think that after a successful .authenticate, the browser tab should be closed as it is no longer needed

Screenshots

Device (please complete the following information!)

• Device: Android pixel 6 simulator, tiramisu. (Happens on any android device)
• OS: tiramisu, API level 33
• flutter_web_auth_2 version: 2.0.0

Additional context

I know that preferEphemeral: true makes the tab close, but it also closes the tab if the user goes to a different app during the login (e.g. to copy a password/mfa code) I think that either Ephemeral tabs should stay open during the login process, or normal tabs should close upon a successful .authenticate

Checklist

• [yup] I have read and followed the entire troubleshooting guide and it has not provided the solution I need.
• [yup] I have provided all the information I can (incl. auth URL etc.) - auth URL is irrelevant to this issue.

Any help is appreciated thanks.

[ThexXTURBOXx]

That's a tricky thing. Maybe it can be done, but I am unsure as of now.
Looking through the documentation of FLAG_ACTIVITY_NO_HISTORY, it states that the newly launched activity (custom tab in our case) will not be kept on the history stack. In my application, that is exactly what I need since there is no MFA or anything.
However, I can see that this might not be the desired behavior. Do you know of any activity flags (or combinations) that might solve the problem at hand already?
If yes, I will try them out as soon as possible and publish a new release with those in place.
If not, I will try to find some better combination myself at some point in the near future

[ThexXTURBOXx]

According to this issue: aboutyou/dart_packages#162
Setting your app's launchMode to either singleTask or singleTop without the preferEphemeral config could also work correctly. However, I did not yet test that.
I will try to see as soon as possible, if that is a proper solution.

[Vikrech]

Hi @ThexXTURBOXx, I wonder do you have any updates regarding this issue?
One more thing I wanted to mention: could it be possible for the CallbackActivity to be launched with the FLAG_ACTIVITY_CLEAR_TOP? As far as I understand, the described solution is implemented in another package sign_in_with_apple SignInWithApplePlugin.kt
Another solution is described here How to close CustomTab

[ThexXTURBOXx]

I already tested most of the flags, but no matter which combination I chose, there will always be some user who will complain.
Hence, I did not look further into this issue.
If you can confirm that your flag does work well and should fit the majority of use cases, I can adjust the package after some more testing.

[Vikrech]

I appreciate your efforts and agree that probably each case would require a unique approach to handle it, but I am still wondering whether we could at least improve the handling of Android Custom Tabs, taking into account the mentioned examples.

[BuzzBumbleBee]

I have ran into this issue recently, would it be possible to supply a "hideBrowserHistory" flag into the authentication flow and keep the default as it is now ?

I think in most cases the end user seeing an extra app spawned in the recent app menu would be a little confusing

[ThexXTURBOXx]

I am a bit reluctant to add another flag to the current authenticate function. I was thinking about maybe abstracting everything into several objects, one for each platform. Then you can specify each setting for each platform independently.
While this would make code within this package much cleaner, everyone else would need to specify more arguments, hence, it is not optimal.

I need to think a bit more about all of this

[ThexXTURBOXx]

The intent flags can now be adjusted using the intentFlags option in 3.0.0-alpha.1