Infeasible
Status Update
No update yet.
Comments
vi...@google.com
These changes would be really nice! Being able to change the text colour is really important as it now doesn't match the rest of our app either.
Stack overflow posting -http://stackoverflow.com/questions/32533069/how-to-change-a-title-color-in-chrome-custom-tabs
Stack overflow posting -
ma...@hypr.com
Changing text color and the overflow icon color is important to us too! Awesome work on the feature though.
vi...@google.com
The ability of customize the status bar color is very important!
vi...@google.com
It is in the essence of a "custom" UI component to have a custom color. Please add this feature!
vi...@google.com
I have noted that the status bar automatically generated from the toolbar color is a bit darker than needed. The status bar color of the chrome activity is different to the one of the rest of my app. It doesn't strictly follow Material guidelines.
Description
After a lot of debugging, we found a issue that needs the combination of android 15 and Chrome 131 (android mobile app).
Our flow is the following:
- start a login flow from chrome app using okta, starts a long polling request
- auth request triggers our android app
- android app verifies if auth is correct and goes through if yes, calling server to validate
- server validates and app shows success
- chrome tab is back on the foreground and long polling request initially created receive success
For android 14 + Chrome 131, the long polling request sustains as the chrome tab is put in the background as the android native auth app is opened, and the flow works
For android 15 + Opera 85 (based on chromium 129), same thing, the flow works
For android 15 + Chrome 131, the long polling request is terminated few seconds after the chrome tab is put in the background as the android native app opens. When the auth is accepted on the app, then we're back on the chrome tab, the POST request has long been killed, and try to restart the flow instead of accepting the auth. Indeed, the server can't reach that request anymore.
Here are some Charles proxy screenshot, one from Chrome 131 and one from Opera 85, both on android 15 (pixel 7 pro). You can see that the POST long polling request lasts 57seconds on Opera, but it's killed after 9 seconds on Chrome.
On android 14 and Chrome 131, this flow worked as the request is not killed when put in background.
My educated guess would be a special optimisation on android 15 + Chrome 131 to kill requests that are still open in the background. Or maybe a security feature to avoid such background request ? Anyway, it's a major issue for our users as android 15 is getting widely adopted since its recent release.