Assigned

Bug

Status Update

No update yet.

Description

ch...@google.com

created issue on behalf of va...@ea.com #1

Apr 3, 2024 05:45AM

Steps to reproduce the problem

Open Custom chrome tab from an Activity
Minimise the custom chrome tab
Close the custom chrome tab

Problem Description

Context:

Our app recently switched to using Custom Chrome Tabs for authentication. WebViews wouldn't allow login from Google and Facebook due to privacy restrictions. Everything worked well using onResume and onNewIntent lifecycle methods to detect when the user closes the Custom Chrome Tab and is redirected back to our app. However, a recent Chrome update introduced a minimize button (Picture-in-Picture mode) for Custom Chrome Tabs. For our authentication flow, this minimize functionality is undesirable. We want the user to complete authentication before interacting with the app again. Unfortunately, modifying Chrome Tab behavior directly is limited due to privacy concerns. Our current issue is that when the user minimizes the Custom Chrome Tab, our app using onResume interprets it as a complete closure. I've explored onMinimized and onUnMinimized APIs from CustomTabCallback, but they don't detect the scenario where the user minimizes and then closes the tab. This leaves our app's activity empty, resulting in a poor user experience.

Question: Are there ways to reliably detect when a minimized Custom Chrome Tab is finally closed by the user? Are there alternative solutions to effectively track the minimize functionality for our authentication process?

Additional Information:

I've explored onMinimized and onUnMinimized APIs from CustomTabCallback. To track the minimized state, I implemented a flag. However, this approach has limitations.

Inside onResume, I use a timer (set to 750 milliseconds) to periodically check the flag. If the flag shows the tab is minimized, I avoid treating it as a closed tab. This introduces a slight delay in detecting the close event, and I'm curious if there are better solutions.

But as I said earlier this solution can resolve detecting the minimize state but when user closes the custom tab when it is in minimized state we dont have any way to detect.

Is there any way to detect the closing of custom tab in minimized state?

Summary

Unable to detect the closing of custom chrome tab in minimised state.

Custom Questions

Which component does this fall under?

Not sure - I don't know

Does this work in other browsers?

Not sure - I don't know

Additional Data

Category: API
Chrome Channel: Stable
Regression: N/A

Comments

si...@google.com <si...@google.com> #2Apr 8, 2024 09:55PM

Assigned to si...@google.com.

Hi, thanks for the report!

Does EngagementSignalsCallback#onSessionEnded achieve what you need? You can check the API's availability using CustomTabsSession#isEngagementSignalsApiAvailable and register the callback using CustomTabsSession#setEngagementSignalsCallback.

kk...@gmail.com <kk...@gmail.com> #3Apr 10, 2024 06:37AM

Hi, I am also impacted by the recent introduction of the minimize button. In an app authentication flow, the minimization is worth nothing, because typically users have to log in to continue using the app.

- Is there any way to disable the minimize button from the calling app?
- If not, another option would be to force close the CustomTab when the app detects the minimized state. Is there a way to force close the CustomTab in the minimized state?

Thanks!

va...@ea.com <va...@ea.com> #4Apr 10, 2024 11:27AM

Hi

Does EngagementSignalsCallback#onSessionEnded achieve what you need?

The main issue with the functionality arises as the onSessionEnded API fails to detect the closing of the browser while the custom chrome tab is in a minimized state. This API works as expected, however, when the custom chrome tab is closed normally.

Steps to reproduce the problem
1. Open Custom chrome tab from an Activity
2. Minimise the custom chrome tab
3. Close the custom chrome tab - Here onSessionEnded API is not getting called.

Message last modified on Apr 10, 2024 11:28AM

si...@google.com <si...@google.com> #5Apr 10, 2024 05:35PM

I'll take a look into #onSessionEnded not working.

Would you be able to use #startActivityForResult?

+Victor for general feedback for MCT and this use-case.

va...@ea.com <va...@ea.com> #6Apr 12, 2024 09:13AM

What do you mean by this "Would you be able to use #startActivityForResult?" ?

si...@google.com <si...@google.com> #7Apr 12, 2024 05:38PM

If you call #startActivityForResult instead of #startActivity to launch the CustomTab, you will get a callback, #onActivityResult, when the CustomTab finishes.

However, I'm investigating a bug that may be preventing the CustomTab from fully closing when it's minimized.

va...@ea.com <va...@ea.com> #8Apr 15, 2024 05:06AM

Thank you for looking into the issue. Do we have any updates on when the minimize functionality for custom chrome tabs will be officially released, I see this is not available to all mobiles yet?

In relation to your statement, "If you call #startActivityForResult instead of #startActivity to launch the CustomTab, you will get a callback, #onActivityResult, when the CustomTab finishes." I'm a bit confused. From my understanding, we cannot control the custom tab activity ourselves - everything is managed by Android once we call the launchUrl API of CustomTabsIntent. Could you possibly provide a sample code snippet to clarify what you're trying to convey?

Message last modified on Apr 15, 2024 05:06AM

si...@google.com <si...@google.com> #9Apr 17, 2024 06:30PM

Unfortunately, I don't have any updates on when the feature is going to be officially released.

However, we've landed a fix for the #onSessionEnded callback. It should be available in the latest Chrome Canary (125.0.6422.2+). Could you verify that this works for you as well? If the minimize button isn't available in Chrome Canary, you can go to chrome://flags, search for "cct-minimized" and enable it. You might need to make Chrome Canary the default browser to make sure the Custom Tab launches in Chrome Canary.

Regarding your question about #startActivityForResult, CustomTabsIntent#launchUrl is just a convenience method. So, you can normally call #startActivity with the intent that you've built using CustomTabsIntent. #startActivityForResult is very similar. However, #startActivityForResult doesn't seem to work as expected with picture-in-picture, so #onSessionEnded seems to be the best option at the moment.

We are also interested in hearing more about how you use Custom Tabs for authentication. If you would like to share more details, feel free to post them here.

kk...@gmail.com <kk...@gmail.com> #10Apr 18, 2024 01:35AM

I'm not the reporter of this bug, but I am using the CCT as instructed by

https://datatracker.ietf.org/doc/html/rfc8252#appendix-B.2

My app shows "Log in" button. When a user clicks the button, CCT shows up. The app waits for custom url scheme or https (deeplink) scheme while users interact with my web server on CCT. When the user completes signing in, the web site call redirects to the url/https schema. The app receives the schema and put an activity over the CCT so that the CCT closes.

https://stackoverflow.com/questions/33795847/how-to-close-chrome-custom-tabs

Also, when the activity just below the CCT becomes foreground, my app assumes that the CCT is closed. So now my app misunderstands that the CCT is closed even when just minimized.

As the app won't do anything without successful authentication, and the user would get no benefit from minimizing the CCT, I don't want to show the minimization button on CCT OR I want to force close the minimized CCT. The way to close CCT (as above) doesn't work with the minimized CCT.

Message last modified on Apr 18, 2024 07:56AM

vg...@google.com <vg...@google.com> #11Apr 18, 2024 06:49PM

Thanks for the feedback and for clarifying your use case. We understand your activity returns to the foreground and therefore the Custom Tab is closed on successful authentication, but what is the UX for users who close the Custom Tab themselves without authenticating and return back to your app? Would it be reasonable to treat a minimized event the same as a close event in terms of the return experience back to your app?

Given Minimized Custom Tabs leverages Picture-in-Picture, we expect users would still be able to interact with your app even if there is a Minimized Custom Tab in PiP mode.

kk...@gmail.com <kk...@gmail.com> #12Apr 19, 2024 01:57AM

I do understand that there are needs of that functionality in some apps. However, in my app's authentication flow, CCT is just another activity. Say, if an unauthenticated user opens Gmail app and is required to sign in, what else can they do without signing in? (I'd imagine if Gmail's Google sign-in screen had a minimize button, it'd be just confusing to users.)

Thus I really appreciate if you can at least provide an option to hide the minimize button.

va...@ea.com <va...@ea.com> #13Apr 19, 2024 07:39AM

I agree with the above requirement. During the authentication process, having a minimize button doesn't make sense. Without authentication, we don't want the user to take any action as they won't be able to do anything.
I would greatly appreciate it if you could provide an option to hide the minimize button on the custom chrome tab.

"Could you verify that this works for you as well? If the minimize button isn't available in Chrome Canary, you can go to chrome://flags, search for "cct-minimized" and enable it. You might need to make Chrome Canary the default browser to make sure the Custom Tab launches in Chrome Canary."

I will update you regarding this, once I get back from vacation.

Message last modified on Apr 19, 2024 07:41AM

tw...@google.com <tw...@google.com> #14Apr 22, 2024 09:24PM

We understand that allowing minimization may not be the preferred UX for all app developers. One of our goals is to provide a consistent and predictable experience for users with regard to Chrome's feature offerings. With that goal in mind, we'd like to get your feedback on the below APIs to address your concerns.

kkoiwai@ -- could you please try the following APIs and let us know if they address your use case?

EngagementSignalsCallback#onSessionEnded: this will be called when the Custom Tab is closed. We recently fixed a bug with this callback, so please test on Chrome Beta or Chrome Dev (available in the Play Store).
CustomTabsCallback#onMinimized/#onUnminimized: these will be called when the Custom Tab is minimized to picture-in-picture or maximized to the regular CustomTabActivity respectively.

I will update you regarding this, once I get back from vacation.

Thanks varikatla@.

kk...@gmail.com <kk...@gmail.com> #15Apr 23, 2024 01:55AM

> could you please try the following APIs and let us know if they address your use case?

My app can be used by those who are very new to Android. For the first time CCT is used in the device, CCT shows a balloon saying minimized feature is added. The users, who don't know what to do next, would naturally tap the minimized button without knowing what happens next. Even if my app can detect the CCT is minimized, only I can do then is to alert the user to close the minimized tab or unminimize it so that the user can restart or continue the authentication session, but it is very difficult to instruct such a user to unfold the small rectangle on a random spot in the screen.

Currently when CCT is minimized in my app, the user would see the "sign-in" button again. The user may tap the button again, then another CCT with sign-in page opens. To accommodate this case, my app has to maintain multiple authentication sessions (i.e. state, nonce, PCKE values etc.) because my app don't know from which CCT the user completes signing in.

Message last modified on Apr 24, 2024 12:14AM

va...@ea.com <va...@ea.com> #16May 7, 2024 08:41AM

> We understand that allowing minimization may not be the preferred UX for all app developers. One of our goals is to provide a consistent and predictable experience for users with regard to Chrome's feature offerings. With that goal in mind, we'd like to get your feedback on the below APIs to address your concerns.

I have tested the EngagementSignalsCallback#onSessionEnded:, it seems working even when custom chrome tab is closed in minimized state, but the user experience when using onSessionEnded is not that good as user will see a blank screen for split sec and for slower mobiles it takes more time. Previously we used to close the custom tab inside onResume which worked seemlessly

So it would be really helpful if you can provide a way to disable minize button from custom chrome tab instead of we using onSessionEnded API.

kk...@gmail.com <kk...@gmail.com> #17May 8, 2024 02:01AM

Just to let you know that we have tried CustomTabsCallback two years ago for other purposes, and we have detected that in some cases the callback was not available and our apps clashed. (We specifically call Chrome so it is not an issue of non-Chrome CT.)

We couldn't reproduce it in our environment (but detected hundreds on Clashlytics) and didn't raise a crbug issue at that time, so we don't know if this still exists or not. Just FYI.

va...@ea.com <va...@ea.com> #18May 14, 2024 01:28PM

Hi
Is there any update regarding our request to include an option to disable or remove the minimized button from the custom Chrome tab, or do we need to solely rely on the #onSessionEnded API? Additionally, could you please inform us about the official release date of this functionality for all mobile devices?

vg...@google.com <vg...@google.com> #19May 15, 2024 08:37PM

Hi there, we understand authentication is a critical use case for Custom Tabs and as such we are actively looking at ways to improve that experience. In the meantime, using #onSessionEnded and #onMinimized are the best mechanisms to detect and act on Minimized Custom Tab changes.

Have you had a chance to try these APIs out and see if they address your use case?

As for an official release date, we will be ramping up Minimized Custom Tabs imminently.

va...@ea.com <va...@ea.com> #20May 17, 2024 12:31PM

Hi

I would like to bring to your attention that I have not yet fully implemented the end-to-end process, my focus has been primarily on exploring the #onSessionEnded API. Prior to this, we were using the #onResume API to detect the closure of a custom tab and responding accordingly.

Transitioning to the #onSessionEnded API represents a significant shift in our approach and as such, implementation has not yet commenced. Before we proceed with this plan, I would like to seek clarification on whether this is the only available option(to use #onSessionEnded API to handle minimized situation), or if there is an alternative solution on the horizon, specifically, the provision to disable the minimized button, this option has a valid use case for authentication.

The direction of our planning will largely be based on your feedback regarding this matter. If an option to disable the button is introduced, it could greatly assist us by eliminating the need for any major changes to our current approach.

Essentially, I am awaiting your guidance on this matter. Thanks for your timely response and support.

vg...@google.com <vg...@google.com> #21May 20, 2024 08:55PM

We have no current plans to provide an explicit opt-out for the minimized Custom Tab button. As mentioned in #c19, we are looking into the authentication use case and will circle back should changes come as a result of this exploration. Currently, #onSessionEnded is our best recommendation and will be reliable regardless of any future product changes in this space.

ni...@appian.com <ni...@appian.com> #22Jun 6, 2024 06:17PM

Any update on this?

We have the same use case of using custom chrome tab for authentication.

Having an explicit opt-out for the minimize custom tab button will significantly reduce the effort required to handle the minimization of custom chrome tab during authentication.

Message last modified on Jun 10, 2024 06:33PM

tw...@google.com <tw...@google.com> #23Jun 12, 2024 04:55PM

We've started working on a purpose built variant of custom tabs for authentication, which won't have a minimize button. We'll be landing an implementation across AndroidX and Chrome in the coming months.

va...@ea.com <va...@ea.com> #24Jun 21, 2024 06:25AM

Hi
Is there any tentative date(month) when we can expect this variant of custom tabs for authentication, which wont have a minimize button?

And also could you please inform us about the official release date of this existing minimize functionality for all mobile devices?

Message last modified on Jun 21, 2024 06:28AM

tw...@google.com <tw...@google.com> #25Jun 21, 2024 05:13PM

> Is there any tentative date(month) when we can expect this variant of custom tabs for authentication, which wont have a minimize button?

We're still in the design phase, after which we'll be able to better determine overall scope and timelines.

> And also could you please inform us about the official release date of this existing minimize functionality for all mobile devices?

The minimized button is fully released on Chrome version 124+.

Message last modified on Jun 21, 2024 05:14PM

ma...@uber.com <ma...@uber.com> #26Jul 3, 2024 10:42AM

We are also leveraging CCTs for Payment method authorization scenarios and canceling users' checkout process when they press the minimize button is bad and confusing UX. However, it seems this is the only option now due to the lack of any option to disable the minimize button.

de...@vinted.com <de...@vinted.com> #27Jul 9, 2024 02:24PM

It sounds that a need for this workaround is necessary because there is no way to detect a case when the user clicks on "Back" button inside CCT. Is there a reason for such functionality not being available? iOS alternative has it.

Also, for me onSessionEnded is called only when the user in CCT chooses to open the url in external browser. It seems that sometimes it is also called on back click, but not on flow completion via deep link.

Message last modified on Jul 9, 2024 02:53PM

tw...@google.com <tw...@google.com> #28Jul 17, 2024 05:16PM

Re #27, #onSessionEnded should also be called if the custom tab is closed due to a back button press. Do you have repro steps that you could share so we can look into what may be going wrong?

> It sounds that a need for this workaround is necessary because there is no way to detect a case when the user clicks on "Back" button inside CCT. Is there a reason for such functionality not being available? iOS alternative has it.

Do you mean the back button in the custom tabs toolbar or the OS back button? For the former, the CCT will be finished so #onSessionEnded should be called. For the latter, Chrome consumes the OS back button event and may do one of many things (e.g. close a sheet, navigate back in tab history, or close the custom tab). If the custom tab is closing, #onSessionEnded should be called.

hu...@gmail.com <hu...@gmail.com> #29Aug 1, 2024 02:54PM

Hello, we are also affected by the introduction of the minimize feature. Is there any update on the Custom Tabs for Authentication? We currently don't use a `CustomTabsSession` so we cannot access the `onMinimize` callback. Refactoring would be impractical for us and the story for using `onMinimize` to cancel authentication and close the tab sounds less than ideal.

va...@ea.com <va...@ea.com> #30Sep 5, 2024 01:46PM

Hi Team
Could you please provide an update on this issue? It would be really helpful for our planning. Thanks!!

tw...@google.com <tw...@google.com> #31Sep 5, 2024 03:21PM

Our team is working on the implementation for a purpose built variant of custom tabs for authentication that will not have the minimized button.

va...@ea.com <va...@ea.com> #32Sep 5, 2024 03:23PM

Thanks for the prompt response, any timeline would really help.

tw...@google.com <tw...@google.com> #33Sep 5, 2024 03:49PM

We haven't locked in a target Chrome milestone for pilots or launch quite yet. We're starting outreach to developers to get feedback on the feature and API design, as well as the initial implementation. We plan to reach out to some of the people who have commented on this bug via email in the next couple of weeks.

kk...@gmail.com <kk...@gmail.com> #34Sep 6, 2024 01:18AM

I am willing to disclose my work email if gmail is not appropriate to get contacted. I look forward to hearing from you. Thanks.

tc...@ampol.com.au <tc...@ampol.com.au> #35Nov 15, 2024 06:16AM

Our team is working on the implementation for a purpose built variant of custom tabs for authentication that will not have the minimized button.

Hey, my team is looking into using this for an authentication flow and would love a purpose built variant for this!

Do you guys have any updates for where this is up to? Cheers

tw...@google.com <tw...@google.com> #36Nov 15, 2024 03:58PM

We've added @Experimental Auth Tab APIs to AndroidX and implemented an MVP of Auth Tab in Chrome. In Chrome, Auth Tab is enabled by default on Chrome versions 132.0.6805.0 and above (currently in Chrome Beta at this time).

We've also added an interim way to check for Auth Tab support using CustomTabsClient#extraCommand starting with Chrome 132.0.6793.0+. Apps can check for support by calling #extraCommand with the commandName ‘isAuthTabSupported’. If Auth Tab is supported, extraCommand will return a Bundle with a key-value pair ‘authTabSupported’-true. You can see how this is implemented here. We plan to use this during our Auth Tab pilot phase, then graduate to a new AndroidX API.

We additionally have work planned to support setting theme colors and receiving basic navigation callbacks. We're targeting implementation in Chrome 133 (release schedule here: https://chromiumdash.appspot.com/schedule).

Anyone is welcome to try out Auth Tab while it's still @Experimental; we'd request that you give our team a heads up so that we can proactively monitor crashes and metrics on our side to ensure there are no issues. The API is subject to change and in the event that we find critical issues during the experimental / pilot phase, we may need to turn off Auth Tab in Chrome, in which case the default fallback would be for a custom tab to be launched instead.

I can work on a public version of an Auth Tab technical overview if anyone is interested in an early integration.

vo...@gmail.com <vo...@gmail.com> #37Feb 26, 2025 07:50PM

Fwiw Auth Tab has landed in androidx.browser 1.9.0-alpha01 https://developer.chrome.com/docs/android/custom-tabs/guide-auth-tab

tw...@google.com <tw...@google.com> #38Mar 5, 2025 04:09PM

Re #37 -- yes, we have published an alpha version of androidx.browser with @Experimental Auth Tab APIs. We have been working with some partners to locally test Auth Tab integrations and if there are no new issues discovered in the next few weeks we plan to remove the @Experimental annotation indicating Auth Tab is ready for general availability.

All apps are welcome to use the Auth Tab APIs while they are in the @Experimental stage / released to alpha, with the caveat that the API surface may change a bit as we finish partner testing and work through Android API Council feedback.

jo...@fundhawk.com <jo...@fundhawk.com> #39Mar 28, 2025 01:25AM

I did a quick Auth Tab patch for the flutter_web_auth_2 package here:

https://github.com/titanous/flutter_web_auth_2/commit/8c32e881329cfaf09f171fd2b1672c892a44c3d6

I've been testing in the latest API 35 emulator with Chrome stable 134.0.6998.135

After navigating to the custom scheme in the auth tab, I'm seeing it close and a "Open with" popover, and the result is only delivered to handleAuthResult after the popover is dismissed by tapping outside of it (there are actually two results delivered, RESULT_OK and then RESULT_CANCELED). Any thoughts on how to narrow down what is causing this?

si...@google.com <si...@google.com> #40Mar 28, 2025 10:01PM

Could you enable External Navigation Debug Logs in chrome://flags then provide the logcat logs with the tags cr_UrlHandler and ActivityTaskManager?

jo...@fundhawk.com <jo...@fundhawk.com> #41Mar 28, 2025 10:15PM

03-28 18:14:22.365   580  1843 I ActivityTaskManager: START u0 {cmp=com.linusu.flutter_web_auth_2_example/com.linusu.flutter_web_auth_2.AuthenticationManagementActivity (has extras)} with LAUNCH_MULTIPLE from uid 10210 (BAL_ALLOW_VISIBLE_WINDOW) result code=0
03-28 18:14:22.585   580  1843 I ActivityTaskManager: START u0 {act=android.intent.action.VIEW cmp=android/com.android.internal.app.ResolverActivity (has extras)} with LAUNCH_MULTIPLE from uid 10210 (BAL_ALLOW_VISIBLE_WINDOW) result code=0
03-28 18:14:22.664   580  1843 I ActivityTaskManager: START u0 {act=android.intent.action.VIEW dat=http://127.0.0.1:43823/... cmp=com.android.chrome/com.google.android.apps.chrome.IntentDispatcher (has extras)} with LAUNCH_MULTIPLE from uid 10210 (BAL_ALLOW_VISIBLE_WINDOW) result code=0
03-28 18:14:22.794   580   611 I ActivityTaskManager: Process system:ui restarted
03-28 18:14:22.794   580   611 I ActivityTaskManager: Process system:ui restarted
03-28 18:14:23.202   580  1715 I ActivityTaskManager: START u0 {act=android.intent.action.VIEW dat=http://127.0.0.1:43823/... flg=0x2800000 cmp=com.android.chrome/org.chromium.chrome.browser.customtabs.CustomTabActivity (has extras)} with LAUNCH_MULTIPLE from uid 10146 (BAL_ALLOW_VISIBLE_WINDOW) result code=0
03-28 18:14:23.513   580   631 I ActivityTaskManager: Displayed com.android.chrome/org.chromium.chrome.browser.customtabs.CustomTabActivity for user 0: +305ms
03-28 18:14:24.308  3984  3984 I cr_UrlHandler: shouldOverrideUrlLoading called on http://127.0.0.1:43823/
03-28 18:14:24.319  3984  3984 I cr_UrlHandler: Initial intent navigation.
03-28 18:14:24.320  3984  3984 I cr_UrlHandler: shouldOverrideUrlLoading result: NO_OVERRIDE
03-28 18:14:26.626  3984  3984 I cr_UrlHandler: shouldOverrideUrlLoading called on foobar://success?code=1337
03-28 18:14:26.630  3984  3984 I cr_UrlHandler: shouldOverrideUrlLoading result: NO_OVERRIDE
03-28 18:14:26.780   580   631 I ActivityTaskManager: Displayed android/com.android.internal.app.ResolverActivity for user 0: +713ms
03-28 18:14:36.215   580   960 W ActivityTaskManager: Duplicate finish request for r=ActivityRecord{ceae18b u0 com.linusu.flutter_web_auth_2_example/com.linusu.flutter_web_auth_2.AuthenticationManagementActivity t26 f}}

si...@google.com <si...@google.com> #42Mar 28, 2025 10:43PM

Thanks for the logs!

Looking at the code, I see here that you call authLauncher.launch before calling intent.launch. Could you try removing the authLauncher.launch?

jo...@fundhawk.com <jo...@fundhawk.com> #43Mar 28, 2025 10:45PM

That fixed it, thanks! (not sure why that extraneous code was there, I think I was chasing down another bug and didn't remove it)

si...@google.com <si...@google.com> #44May 2, 2025 11:06PM

PSA: We've removed the experimental annotation from Auth Tab in the androidx.browser 1.9.0-alpha03 release.

br...@pingidentity.com <br...@pingidentity.com> #45May 5, 2025 05:00PM

Thanks! When do we expect for the `alpha` tag to be removed and this be GA'd?

tw...@google.com <tw...@google.com> #46May 5, 2025 06:21PM

It will take around two months to progress the AndroidX APIs from alpha to beta, rc, and finally stable (2 week minimum gap between each stage).

br...@pingidentity.com <br...@pingidentity.com> #47May 5, 2025 06:49PM

Great, thanks for the prompt response. We'll keep an eye out.