Repository navigation
[url_launcher] supportsCloseForLaunchMode calls supportsMode, so it answers "can this mode be launched" instead of "can it be closed" #192758
Description
Steps to reproduce
url_launcher's supportsCloseForLaunchMode is documented as reporting whether closeInAppWebView() will work for a given mode, but its body is identical to supportsLaunchMode's — both call the platform interface's supportsMode. The platform interface declares a separate supportsCloseForMode, which is what it should call, and which the platform implementations do implement differently.
packages/url_launcher/url_launcher/lib/src/url_launcher_uri.dart (v6.3.2, the current release):
Future<bool> supportsLaunchMode(LaunchMode mode) {
return UrlLauncherPlatform.instance.supportsMode(convertLaunchMode(mode));
}
/// Returns true if [closeInAppWebView] is supported for [mode] in the current
/// platform implementation.
///
/// If this returns false, [closeInAppWebView] will not work when launching
/// URLs with [mode].
Future<bool> supportsCloseForLaunchMode(LaunchMode mode) {
return UrlLauncherPlatform.instance.supportsMode(convertLaunchMode(mode)); // <-- should be supportsCloseForMode
}The two implementations genuinely disagree, which is what makes this observable rather than cosmetic. On Android (url_launcher_android 6.3.33):
Future<bool> supportsMode(PreferredLaunchMode mode) async {
switch (mode) {
...
case PreferredLaunchMode.inAppBrowserView:
return _hostApi.supportsCustomTabs(); // true on a device with Chrome
...
}
}
Future<bool> supportsCloseForMode(PreferredLaunchMode mode) async {
return mode == PreferredLaunchMode.inAppWebView; // false for inAppBrowserView
}So on Android:
final canClose = await supportsCloseForLaunchMode(LaunchMode.inAppBrowserView);
// canClose == true (it actually answered supportsCustomTabs())
await launchUrl(uri, mode: LaunchMode.inAppBrowserView);
await closeInAppWebView();
// nothing closes — a Custom Tab is not closable, which is exactly what
// supportsCloseForMode was telling the caller and what the public API hid.url_launcher_ios 6.4.2 draws the same distinction the other way round (its supportsCloseForMode returns true for both inAppWebView and inAppBrowserView), so the two methods are meaningfully different on every platform — the public API just never asks the right one.
Expected results
supportsCloseForLaunchMode(LaunchMode.inAppBrowserView) reports whether closeInAppWebView() can close that mode — false on Android, per url_launcher_android's own supportsCloseForMode.
Actual results
It reports whether that mode can be launched — true on any Android device with Chrome — so a caller that branches on it does the opposite of what the documentation promises.
Suggested fix
One line:
Future<bool> supportsCloseForLaunchMode(LaunchMode mode) {
return UrlLauncherPlatform.instance.supportsCloseForMode(convertLaunchMode(mode));
}Worth a regression test asserting the two public methods can disagree, since they currently cannot: a fake platform returning true from supportsMode and false from supportsCloseForMode would have caught this and would keep catching it.
Code sample
Code sample
import 'package:url_launcher/url_launcher.dart';
Future<void> main() async {
final uri = Uri.parse('https://flutter.dev');
// On Android, with Chrome installed:
print(await supportsLaunchMode(LaunchMode.inAppBrowserView)); // true
print(await supportsCloseForLaunchMode(LaunchMode.inAppBrowserView)); // true <-- expected false
}Version / environment
url_launcher6.3.2 (latest on pub.dev at time of filing, published 2025-07-10)url_launcher_platform_interface2.3.2 — declaressupportsCloseForModeatlib/src/url_launcher_platform.dart:114url_launcher_android6.3.33,url_launcher_ios6.4.2
Found by reading the sources while choosing a browser hand-off strategy; our own code calls closeInAppWebView() unconditionally and swallows the result, so we are not affected — filing because the next caller who trusts the documented method will be.
Activity
suryaKommana2662 commentedon Sep 15, 2026
@stephane-segning Thanks for the detailed report. I was able to reproduce the issue locally on Android and iOS. Using
LaunchMode.inAppBrowserView, I observed:Reproduced locally on Flutter 3.47.4 stable with
url_launcherusing an Android 17 (API 37) emulator with Chrome/Custom Tabs available. Routing toteam-ecosystemfor further investigation.Flutter Doctor Output[url_launcher] Fix supportsCloseForLaunchMode to query close support (f…
github-actions commentedon Oct 16, 2026
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 -vand a minimal reproduction of the issue.