Skip to content

Use Chrome Custom Tab in url_launcher, instead of custom WebView activity #18589

Description

@alanrussian

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

Activity

  1. added this to the milestone on Dec 4, 2018
  2. thedejifab commented on Feb 13, 2019

    @thedejifab
  3. estevez-dev commented on Feb 20, 2019

    @estevez-dev
  4. added
    P2Important issues not at the top of the work list
    on May 29, 2020
  5. removed this from the milestone on Aug 17, 2020
  6. daniellampl commented on Jun 14, 2021

    @daniellampl
  7. varpa89 commented on Oct 13, 2021

    @varpa89
  8. florian-obernberger commented on Dec 10, 2022

    @florian-obernberger
  9. 12 remaining items

  10. added
    P3Issues that are less important to the Flutter project
    triaged-androidTriaged by Android platform team
    and removed
    P2Important issues not at the top of the work list
    on Jul 13, 2023
  11. reidbaker commented on Jul 13, 2023

    @reidbaker
    Contributor

    @mariamhas to confirm priority is correct.

  12. gnprice commented on Aug 17, 2023

    @gnprice
    Member

    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:

    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.inAppWebView on Android, where it's also our default behavior.)

  13. gnprice commented on Aug 17, 2023

    @gnprice
    Member

    Another 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.)

  14. 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
  15. cachapa commented on Aug 17, 2023

    @cachapa
    Contributor

    I want to add that many OAuth terms of service explicitly forbid using webviews to limit exposure of the user's login credentials.

    Here's a relevant Google recommendation.

  16. added a commit that references this issue on Aug 31, 2023
    e668c43
  17. stuartmorgan-g commented on Aug 31, 2023

    @stuartmorgan-g
    Contributor

    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)

  18. github-actions commented on Sep 14, 2023

    @github-actions

    This 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 -v and a minimal reproduction of the issue.

  19. locked as resolved and limited conversation to collaborators on Sep 14, 2023
  20. added a commit that references this issue on Jun 10, 2026
    5da8d44
  21. added a commit that references this issue on Jun 19, 2026
    61f1022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projectc: new featureNothing broken; request for a new capabilitycustomer: crowdAffects or could affect many people, though not necessarily a specific customer.customer: mulligan (g3)p: url_launcherPlugin to launch external applicationspackageflutter/packages repository. See also p: labels.platform-androidAndroid applications specificallyteam-androidOwned by Android platform teamtriaged-androidTriaged by Android platform team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions