Skip to main content

Weird Web Share API

Over on Job Garden we were looking at using the Web Share API to add native share dialogs to some pages but it proved more tricky than I was expecting. I made a very simple page to test it out, and here’s some more background…

A screenshot of a share sheet
Safari on IOS 13.4

The API provides a way to have a little JavaScript-powered link or button that will open a dialog for doing things with the page’s URL, like share over email, copy it to the clipboard, add to your favourite “read later” service, etc.

Currently, this feature — navigator.share() — is only supported in Safari (both macOS and iOS) and in Chrome for Android. Usually I wouldn’t bother using something with such little support but given it requires so little JavaScript, and has a nice, native result, why not?

A screenshot of a share sheet
macOS Safari 13.0.1

However, despite reading a bunch of things about it, like this CSS Tricks article, I didn’t notice any describing the weird issues I was finding with it. Then we remembered Jeremy Keith’s post from a while back and realised it wasn’t just us.

Here’s the problem… When triggering the sharing you can supply three fields: url, title and text. Unfortunately which of these get shared is unpredictable. For example, on macOS Safari, sharing with Mail:

  • If url, title and text are shared, only url and text make it to an email.
  • If url and title are shared, only url makes it.
  • If url and text are shared, both make it.

It’s the same with other choices, such as using iOS Safari and copying to the clipboard. Very frustrating. It seems that only using url and text is the best thing to do at the moment. Thanks to Jeremy’s original post there is a bug report for WebKit so it this is at least officially-recognised weird behaviour.

As a simple means of trying this out, I put together that very simple page for testing, so feel free to give it a whirl. If you have Chrome on Android (which I don’t) I’d be interested to hear if it works as expected for you. Apparently the behaviour is the same in Chrome on Android.

UPDATE: A private correspondent points out that the spec for the API is in draft and it suggests that the title can be ignored:

text member
Arbitrary text that forms the body of the message being shared.
title member
The title of the document being shared. May be ignored by the target.
url member
A URL string referring to a resource being shared.

Which seems odd. And it seems odder that, currently, implementations go with this and often ignore the title.

UPDATE 2: Matthew Buckett emails to say that using Chrome on Android, and sharing to GMail, the title becomes the email’s subject line, with text and url appearing in the body, which is what I’d hoped would be standard behaviour.