Repository navigation
Use Chrome Custom Tab in url_launcher, instead of custom WebView activity #18589
Description
Activity
- addedc: new featureNothing broken; request for a new capabilityNothing broken; request for a new capability
on Dec 4, 2018 - addedp: url_launcherPlugin to launch external applicationsPlugin to launch external applications
on Feb 14, 2019 This can help: https://pub.dartlang.org/packages/flutter_custom_tabs
Reacted by Ayodeji Fabusuyi, Clifton Labrum and Alessandro Rossi- addedP2Important issues not at the top of the work listImportant issues not at the top of the work list
on May 29, 2020 - addedcustomer: crowdAffects or could affect many people, though not necessarily a specific customer.Affects or could affect many people, though not necessarily a specific customer.
on Mar 1, 2021 florian-obernberger commented
on Dec 10, 2022 on Dec 10, 2022 · Hidden as off-topicshow commentMore actions12 remaining items
- addedP3Issues that are less important to the Flutter projectIssues that are less important to the Flutter projecttriaged-androidTriaged by Android platform teamTriaged by Android platform teamand removedP2Important issues not at the top of the work listImportant issues not at the top of the work list
on Jul 13, 2023 @mariamhas to confirm priority is correct.
It would be great to fix this, because the current behavior (that hand-rolled webview window) is a very odd UX for when the user wanted to open a web page.
Specifically:
- The system status bar is hidden. That would be appropriate for playing a game, or for a lightbox-style display of a photo. It's not normal for simply viewing a web page.
- There's no app bar — so no title orienting the user with "yep, this is a web page, here's the website you're on"; no close button; no share button; no overflow menu for other features like "refresh" or "go forward" or "open in a browser app".
Here's a screen recording showing the current UX:
device-2023-08-16-204847.mp4
All told, as a user this UX doesn't feel like I'm getting a web browser. Or it feels like there's something wrong and broken — it's like how sometimes on a desktop OS if the system window manager crashes then all the applications appear without their title bars and close/maximize buttons.
This odd UX has led to a couple of reports in addition to this thread:
- [url_launcher] Android status bar hidden with inAppWebView mode (without Custom Tabs) #120883 is about the hidden status bar.
- The lack of a close button has been reported as a comment on that other issue.
A Chrome custom tab would resolve those, and provide all of the other browser-style features mentioned above. It's the UX I'm accustomed to seeing in a wide range of Android apps when I follow a link from some content in the app out to an arbitrary web page, and it works nicely.
(And mentioning partly for the sake of search: the behavior we're talking about in this thread is that of
LaunchMode.inAppWebViewon Android, where it's also our default behavior.)Reacted by Philipp BauerAnother issue which would also get resolved automatically if we switched to a Chrome custom tab:
When a Chrome custom tab is opened at a URL that turns out to provide a PDF, it goes ahead and starts downloading the file and then offers it for the user to open in an appropriate app. (At least that's what I see when I try following a link to such a URL in a non-Flutter app that uses Chrome custom tabs.)
Another such issue:
(I've reproduced that issue, and then gone and opened the same web page in a Chrome custom tab in a non-Flutter app and the same
mailto:link successfully opened a mail client ready to compose a message to the given recipient.)Reacted by Philipp Bauer- changed the title
[-]Support Chrome Custom Tabs in UrlLauncher plugin[/-][+]Use Chrome Custom Tab in url_launcher, instead of custom WebView activity[/+]on Aug 17, 2023 I want to add that many OAuth terms of service explicitly forbid using webviews to limit exposure of the user's login credentials.
Reacted by Greg Price- added a commit that references this issue
on Aug 31, 2023 This new mode will be supported for devices with Custom Tabs support (which will depend on installed browsers), and when not explicitly passing headers that aren't supported.
If for some reason someone wants to force the old webview behavior, you can do so by passing an arbitrary header in the launch request (e.g.,
'prevent-custom-tabs': true)Reacted by hongquang198This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Sep 14, 2023 - added a commit that references this issue
on Jun 10, 2026 - added a commit that references this issue
on Jun 19, 2026
On Android, most apps today tend to use Chrome custom tabs for launching URLs. This provides users with a more seamless experience from their app to the web page that's being launched vs. directly launching the browser.
See comparison: https://developer.chrome.com/multidevice/android/customtabs