Review Copy-Paste vs. Mailto, Long URLs, etc

[aravindet]

We should review the whole workflow. The ecosystem have changed during the last two years since STI, and we need to really think about the best mix to support the platforms/browsers today.

In the onepage (#122) branch I've split the isMobile flag into two - supportsLongUrls and supportsMailto. If supportsMailto is true, we show a single "Send Email" button, otherwise separate Gmail, Yahoo buttons; If supportsLongUrls is true, we add the body to those URLs. All four combinations are supported.

This is my thinking:

supportsMailto is true on:

• All mobile devices, irrespective of browser. They all have a mail client and people usually set those up.
• Desktop Firefox and Chrome. While Desktop users tend to use webmail clients, these browsers support the navigator.registerProtocolHandler() API and

supportsLongUrls is true on:

• All operating systems apart from Windows. (This includes Desktop macOS and Linux but excludes any remaining Windows Phone devices)
• (Perhaps?) Firefox and Chrome on Windows, assuming the protocol handler is a web mail client? This needs some experimentation - maybe someone with Windows could construct and click a 10kb mailto: link?

Thoughts?

[jace]

We also need supportsCc and supportsBcc since we've discovered webmail clients that have trouble with this. Microsoft Outlook (Live/Office) doesn't support BCC. ProtonMail doesn't support CC either.

Incidentally, I stumbled on this list of mailto URLs.

[aravindet]

Yes, but that's a different concern. This issue is about what we can detect automatically in order to decide 1. showing only mailto vs multiple options, and 2. passing the body in the URL vs copying it to the clipboard.

URL construction based on the user's choice is a different issue.

My suggestion is to show only the mailto button and to put the body in URL on all browsers except IE, Edge and Safari on desktop, subject to verification of long URL support on Chrome and Firefox on Windows.

[aravindet]

Done some research:

                        longurl    mailto
Desktop IE/Edge               N         N
Mobile IE/Edge                N         Y
All other mobile              Y         Y
Desktop Chrome/Firefox        Y         Y
All other desktop             Y         N

[aravindet]

The key benefit is that moving Desktop Firefox out of the copy-paste flow (long URLs are supported!) should eliminate most cases of automatic copy failing and having to fall back to the manual copy workflow. (Blocking clipboard access is a Firefox thing.)