url_launcher canLaunch false for mailto links containing subject on iOS

[CoreyCole]

Steps to Reproduce

1. create a flutter application with the url_launcher plugin (url_launcher: 5.1.4)
2. run app on iOS device (simulator supposedly does not work for mailto link handling)
3. canLaunch returns true for a link without a subject

await canLaunch('mailto:placeholder@google.com') == true

4. canLaunch returns false for a link with a subject

await canLaunch('mailto:placeholder@google.com?subject="Test Subject"') == false

From apple's documentation it seems mailto links with a subject field are supported.

Target Platform: ios
Target OS version/browser: 12.4.1
Devices: iPhone SE

Logs

[+2344 ms] flutter: launching mailto:support@storybridgeapp.com?subject="Test Subject"
[        ] flutter: can launch email? false

[+1809 ms] flutter: launching mailto:support@storybridgeapp.com
[        ] flutter: can launch email? true

# flutter analyze
   info • This class (or a class which this class inherits from) is marked as '@immutable', but one or more of its instance fields are not
          final: Provider.bloc • lib/src/blocs/provider.dart:7:7 • must_be_immutable
   info • The value of the field '_observer' isn't used • lib/src/blocs/services/analytics_service.dart:19:29 • unused_field

2 issues found. (ran in 6.1s)

# flutter doctor -v
[✓] Flutter (Channel stable, v1.9.1+hotfix.4, on Mac OS X 10.14.6 18G95, locale en-US)
    • Flutter version 1.9.1+hotfix.4 at /Users/corey/flutter
    • Framework revision cc949a8e8b (11 days ago), 2019-09-27 15:04:59 -0700
    • Engine revision b863200c37
    • Dart version 2.5.0


[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/corey/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Users/corey/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/corey/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.1, Build version 11A1027
    • CocoaPods version 1.7.5

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 40.0.2
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] VS Code (version 1.38.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.5.1

[✓] Connected device (1 available)
    • Omnivor iPhone SE • 4723c97b1224bdc089fdce505d12715f1a3bf37c • ios • iOS 12.4.1

• No issues found!

[stuartmorgan-g]

That's not a valid URL, since it contains a space. Does it work if you properly encode the URL component?

[CoreyCole]

Thank you @stuartmorgan! I fixed the problem following advice from #10032

static final String _emailSubject = 'Test Subject';
static final String _emailLaunchString = Uri.encodeFull('mailto:placeholder@google.com?subject=$_emailSubject');
// ...
await canLaunch(_emailLaunchString) == true

Do you think url_launcher should encode the uri automatically for iOS? This would make it a consistent API for both iOS and Android. In my opinion, it is kind of a weird flutter developer experience that android accepts non-encoded spaces and iOS does not.

At the very least, we should add to the the readme on the package page that instructs developers to use Uri.encodeFull() for a consistent experience on both iOS and Android.

[stuartmorgan-g]

It's impossible to correctly encode an arbitrary string correctly without knowing how it was constructed and what the intent is; see my comments on the PR and other issue.

(Not to mention that encoding a URI isn't idempotent, so doing that even as a "best effort" would corrupt URLs that had already been correctly encoded.)

[CoreyCole]

Moving our discussion from #10032 to here to not spam notifications on a dead thread.

it's not clear to me how building it into url_launcher make sense. That would add complexity for those who are fine with the existing APIs, while at the same time making it impossible for people to use it in other contexts

My proposal is not a breaking change. The existing method that takes an arbitrary encoded url string would still exist.

it seems like a good solution would be to make a package that provided special-case construction for whatever specific schemes you are interested in, and then people who don't like the existing Uri APIs could use your package to make URIs instead

Interesting idea, but in my opinion this increases total complexity, while adding a wrapper method in the url_launcher package itself would reduce total complexity (for a beginner flutter developer using the url_launcher API). I think me and you look at complexity in different ways, and that's okay :)

My only goal is to make flutter accessible to all: both seasoned native/systems developers and beginner junior developers starting their app development journey with flutter.

I think we agree the most actionable item at the moment is for me to fix my documentation example PR following your recommendations. I will verify it works in my app with the Uri constructor.

[stuartmorgan-g]

My proposal is not a breaking change.

I never said it was.

I think you are probably reading "complexity" to mean something like the opposite of "simple to use". I'm actually taking about the technical concept of API complexity: an API that builds N ways of doing something into the API surface has higher complexity than an API with one way of doing that thing (which may or may not make it easier to use in isolation). And as a system, APIs that don't allow composition have higher complexity than those that do because of the resulting proliferation of similar clusters of methods. (Consider the case where there are three plugins that take these kinds of URLs, and imagine how your proposal scales. Now repeat with ten or more.)

I would encourage you to consider your proposal in the context of the design of Flutter as a whole. Consider, for instance, the way padding is done via widget composition rather than by having a padding argument in every widget. It's the same principle.

[CoreyCole]

Thank you for the extended explanation. The composition argument makes sense and the comparison to the Padding widget is an illuminating example for me. I agree now that any wrapper methods should be separated into a different package built on top of url_launcher. But, I think better documentation will prevent the need to build any wrappers.

On the documentation front, unfortunately, the Uri constructor isn't seamlessly compatible. I need to remove the "//" that it adds into the String:

final Uri _emailLaunchUri = Uri(
  scheme: 'mailto',
  userInfo: 'smith',
  host: 'example.com',
  queryParameters: {
    'subject': 'Example Subject & Symbols are allowed!'
  }
);
final String _emailLaunchString = _emailLaunchUri.toString();
// toString() == "mailto://smith@example.com?subject=Example+Subject+%26+Symbols+are+allowed%21"
// this url with the // is incompatible with url_launcher
// because the url_launcher includes those slashes in the "To" field for the email
final String _emailLaunchStringCleaned = _emailLaunchString.replaceFirst(RegExp(r'//'), '');
// removing the // makes it work as intended
// ...
canLaunch(_emailLaunchStringCleaned);
launch(_emailLaunchStringCleaned);

I'm not sure I would want to recommend this method in the documentation either. Am I missing something here?

Thanks again for all the help and patience @stuartmorgan, I really appreciate it :)

[stuartmorgan-g]

RFC 3986 gives a mailto example, and indicates that the email address constitutes the path; your constructor should be:

final Uri _emailLaunchUri = Uri(
  scheme: 'mailto',
  path: 'smith@example.com',
  queryParameters: {
    'subject': 'Example Subject & Symbols are allowed!'
  }
);

// this url with the // is incompatible with url_launcher

This has nothing to do with url_launcher, that's just not a valid mailto URL.

I agree now that any wrapper methods should be separated into a different package built on top of url_launcher.

That was not what I was suggesting, actually; there's no reason for such a package to involve url_launcher at all. I was suggesting that you make a package that constructs URLs (either Url or String, as you prefer) using whatever structured input you want. Then the result can be passed to anything that uses a URL, including url_launcher.