Intent to Ship: Web Share on Android
259 views
Skip to first unread message
Matt Giuca
Jun 13, 2017, 2:21:16 AM6/13/17
to blink-dev, Owen Campbell-Moore, Sam McNally, Ben Wells
Contact emails
[email protected], [email protected]
Spec
https://wicg.github.io/web-share/
TAG review
https://github.com/w3ctag/design-reviews/issues/179
Summary
Web Share is an API for sharing data (text and URLs) from the web to an app of the user's choosing. In this first phase, we only plan to support website-to-native-app sharing, and only in Chrome for Android.
The navigator.share method triggers a SEND intent on Android. We later hope to allow websites to receive SEND intents using the Web Share Target API, but that will be dealt with in a separate proposal.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/1BOhy5av8MQ/OPPt76oZCQAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No, only Android. This feature requires separate implementation on each platform. Also, on Desktop platforms we do not plan to integrate (at least initially) with the OS’s share system, instead we will be blocked on Web Share Target to make this work on those platforms.
Demo link
https://wicg.github.io/web-share/demos/share.html
Link to Origin Trial feedback summary
https://groups.google.com/a/chromium.org/d/topic/blink-dev/rgIpGcOyDKI/discussion (M56)
https://groups.google.com/a/chromium.org/d/topic/blink-dev/kSEGnTX2dsA/discussion (M57)
Interoperability and Compatibility Risk
Low, since this is an optional API (sites won’t stop working if the API doesn’t exist), and we have encouraged use of feature detection.
If we cannot subsequently standardize the Web Share Target API, then this will be limited to sharing from the web to native apps, and may not be supportable on all platforms.
Edge: No signals
Firefox: Public support (expressed interest)
Safari: Public support (expressed interest)
Web developers: Positive
Is this feature fully tested by web-platform-tests?
No. As with other UI and device APIs, it is difficult to test in a cross-browser way because it would require a way to stub out the user-agent-specific UX. In Chrome’s layout tests, we mock out the Mojo service, but this isn’t portable.
See https://crbug.com/730333 (discusses manual testing).
OWP launch tracking bug
Entry on the feature dashboard
Rick Byers
Jun 16, 2017, 3:24:13 PM6/16/17
to Matt Giuca, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally
LGTM1, I'm excited to see this ship, especially given the interest from Twitter etc.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcbn5Q%2BXJticoBDDecgCFaLc_dnpWd6r-vrwJo46tSYc8A%40mail.gmail.com.
Mike Lawther
Jun 18, 2017, 9:42:41 PM6/18/17
to Rick Byers, Matt Giuca, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally
Seeing Twitter actually implement this in their PWA was super cool - and then it was sad but of course the right thing to do for us to turn off the Origin Trial on schedule.
Have an excited, but non-owner LGTM :)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9rpNB3%2BbNYLpKhzZY2GbojDbfE4dDuE3PDag6%2B4oU71w%40mail.gmail.com.
Mike West
Jun 20, 2017, 6:57:27 AM6/20/17
to Matt Giuca, Rick Byers, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
I'm also enthusiastic about shipping this on Android! It fills a clear hole in the platform, and there's certainly developer interest. I have two questions about the effect on other platforms, one theoretical, one practical:
1. I'm curious about the decision not to integrate with the OS-level sharing mechanism on desktop. Can you elaborate a bit on why you're limiting desktop sharing to webby targets in the future?
2. If you're only shipping on Android, do you plan to expose the API on desktop platforms? If so, I suppose `navigator.share()` would reject with an `AbortError`, based on https://wicg.github.io/web-share/#share-method? Does that give developers enough information to determine whether a call to `navigator.share()` could possibly succeed? Perhaps something like `NotSupportedError` would be appropriate in that case?
-mike
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC7btF7R9XvsGuan6EjhTzCLBDPXBiin_sJ4PnQF4-kGo9rE_Q%40mail.gmail.com.
Matt Giuca
Jun 21, 2017, 12:32:54 AM6/21/17
to Mike West, Rick Byers, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
An update on "Is this feature fully tested by web-platform-tests?":
I was convinced to write mostly-manual tests for WPT and have converted our local LayoutTests over. There's now a very comprehensive set of browser-neutral tests being reviewed here.
On Tue, 20 Jun 2017 at 21:57 Mike West <[email protected]> wrote:
I'm also enthusiastic about shipping this on Android! It fills a clear hole in the platform, and there's certainly developer interest. I have two questions about the effect on other platforms, one theoretical, one practical:1. I'm curious about the decision not to integrate with the OS-level sharing mechanism on desktop. Can you elaborate a bit on why you're limiting desktop sharing to webby targets in the future?
The statement about not integrating with OS share systems is pragmatic (and can change). Both Windows and Mac have native sharing systems which we are happy to integrate with if it's feasible, but we haven't investigated either in much detail, and we don't want to block on it. (On Windows, for instance, it might not be feasible as it seems to require a UWP API which Chrome does not have access to).
2. If you're only shipping on Android, do you plan to expose the API on desktop platforms? If so, I suppose `navigator.share()` would reject with an `AbortError`, based on https://wicg.github.io/web-share/#share-method? Does that give developers enough information to determine whether a call to `navigator.share()` could possibly succeed? Perhaps something like `NotSupportedError` would be appropriate in that case?
Good question! No, we do not plan to have the share method exist on platforms that we have not rolled out the API. The API is designed such that you can use the presence or absence of the share method to determine whether share is likely to succeed (under the assumption that if share is supported on a given platform, there will always be at least one target, even if it's "Copy to Clipboard"). That's why we didn't add a dedicated method for feature detection.
(Put another way, there is no need for developers to distinguish between "this user agent doesn't support navigator.share" versus "this user agent supports navigator.share on other platforms, but not on this platform".)
There was a long discussion about this in September 2016 on GitHub, where we reached consensus to remove the proposed "canShare" method. It's still not clear to me that this was the right decision (since you may have a platform where there may or may not be share targets, and there is no way for the user agent to communicate that to the site before the call to share()). But if it proves to be a problem, we can always add it later. It certainly isn't a problem on Android because there are always share targets.
Mike West
Jun 21, 2017, 1:41:36 AM6/21/17
to Matt Giuca, Rick Byers, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
LGTM2 to ship on Android.
On Wed, Jun 21, 2017 at 7:32 AM, Matt Giuca <[email protected]> wrote:
An update on "Is this feature fully tested by web-platform-tests?":I was convinced to write mostly-manual tests for WPT and have converted our local LayoutTests over. There's now a very comprehensive set of browser-neutral tests being reviewed here.
Great to see, thanks!
On Tue, 20 Jun 2017 at 21:57 Mike West <[email protected]> wrote:I'm also enthusiastic about shipping this on Android! It fills a clear hole in the platform, and there's certainly developer interest. I have two questions about the effect on other platforms, one theoretical, one practical:1. I'm curious about the decision not to integrate with the OS-level sharing mechanism on desktop. Can you elaborate a bit on why you're limiting desktop sharing to webby targets in the future?The statement about not integrating with OS share systems is pragmatic (and can change). Both Windows and Mac have native sharing systems which we are happy to integrate with if it's feasible, but we haven't investigated either in much detail, and we don't want to block on it. (On Windows, for instance, it might not be feasible as it seems to require a UWP API which Chrome does not have access to).
Got it, thanks. It seems like it would be worth our time to integrate with those platform-level features for parity with other native apps on those platforms, but I recognize that that's probably not the best use of your time right now. Perhaps it's something we could revisit when y'all get closer to shipping Web Share Targets?
2. If you're only shipping on Android, do you plan to expose the API on desktop platforms? If so, I suppose `navigator.share()` would reject with an `AbortError`, based on https://wicg.github.io/web-share/#share-method? Does that give developers enough information to determine whether a call to `navigator.share()` could possibly succeed? Perhaps something like `NotSupportedError` would be appropriate in that case?Good question! No, we do not plan to have the share method exist on platforms that we have not rolled out the API. The API is designed such that you can use the presence or absence of the share method to determine whether share is likely to succeed (under the assumption that if share is supported on a given platform, there will always be at least one target, even if it's "Copy to Clipboard"). That's why we didn't add a dedicated method for feature detection.
Ok. This is similar to the approach we've taken for things like WebBluetooth and `Notification.image`, so walking along that well-paved path seems reasonable, and makes feature-detection simpler, as you note.
(I'll admit that these platform-specific variances are pretty annoying when shipping new features, as it means that we need to update several platform-specific webexposed tests, but that's a reason to improve our tooling, not to expose potentially confusing no-ops to developers.)
-mike
Dimitri Glazkov
Jun 21, 2017, 3:21:56 PM6/21/17
to Mike West, Matt Giuca, Rick Byers, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
LGTM3
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeE619LZkDCsfkk2%2BvZddwyFjvH99HSuNw2RnJKGgsdSA%40mail.gmail.com.
Rick Byers
Jun 21, 2017, 3:51:02 PM6/21/17
to Mike West, Matt Giuca, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
On Wed, Jun 21, 2017 at 2:41 AM, Mike West <[email protected]> wrote:
LGTM2 to ship on Android.
On Wed, Jun 21, 2017 at 7:32 AM, Matt Giuca <[email protected]> wrote:An update on "Is this feature fully tested by web-platform-tests?":I was convinced to write mostly-manual tests for WPT and have converted our local LayoutTests over. There's now a very comprehensive set of browser-neutral tests being reviewed here.Great to see, thanks!On Tue, 20 Jun 2017 at 21:57 Mike West <[email protected]> wrote:I'm also enthusiastic about shipping this on Android! It fills a clear hole in the platform, and there's certainly developer interest. I have two questions about the effect on other platforms, one theoretical, one practical:1. I'm curious about the decision not to integrate with the OS-level sharing mechanism on desktop. Can you elaborate a bit on why you're limiting desktop sharing to webby targets in the future?The statement about not integrating with OS share systems is pragmatic (and can change). Both Windows and Mac have native sharing systems which we are happy to integrate with if it's feasible, but we haven't investigated either in much detail, and we don't want to block on it. (On Windows, for instance, it might not be feasible as it seems to require a UWP API which Chrome does not have access to).Got it, thanks. It seems like it would be worth our time to integrate with those platform-level features for parity with other native apps on those platforms, but I recognize that that's probably not the best use of your time right now. Perhaps it's something we could revisit when y'all get closer to shipping Web Share Targets?
IMHO the main concern here is that the API is designed in such a way that it COULD in theory be integrated with the native sharing facilities (otherwise we risk never having interop with Edge and Safari, etc.). IIRC we have reason to believe the risk is low here, right Matt?
2. If you're only shipping on Android, do you plan to expose the API on desktop platforms? If so, I suppose `navigator.share()` would reject with an `AbortError`, based on https://wicg.github.io/web-share/#share-method? Does that give developers enough information to determine whether a call to `navigator.share()` could possibly succeed? Perhaps something like `NotSupportedError` would be appropriate in that case?Good question! No, we do not plan to have the share method exist on platforms that we have not rolled out the API. The API is designed such that you can use the presence or absence of the share method to determine whether share is likely to succeed (under the assumption that if share is supported on a given platform, there will always be at least one target, even if it's "Copy to Clipboard"). That's why we didn't add a dedicated method for feature detection.Ok. This is similar to the approach we've taken for things like WebBluetooth and `Notification.image`, so walking along that well-paved path seems reasonable, and makes feature-detection simpler, as you note.
Agreed. We believe this is simpler for developers from a predictability perspective (since they almost always need to worry about whether a new feature is supported by the browser being used).
(I'll admit that these platform-specific variances are pretty annoying when shipping new features, as it means that we need to update several platform-specific webexposed tests, but that's a reason to improve our tooling, not to expose potentially confusing no-ops to developers.)
+1. This is a bug for the new feature control team which now owns this previously un-owned tooling :-)
-mike
Matt Giuca
Jun 21, 2017, 7:46:54 PM6/21/17
to Rick Byers, Mike West, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther
On Thu, 22 Jun 2017 at 06:51 'Rick Byers' via blink-dev <[email protected]> wrote:
On Wed, Jun 21, 2017 at 2:41 AM, Mike West <[email protected]> wrote:LGTM2 to ship on Android.
On Wed, Jun 21, 2017 at 7:32 AM, Matt Giuca <[email protected]> wrote:An update on "Is this feature fully tested by web-platform-tests?":I was convinced to write mostly-manual tests for WPT and have converted our local LayoutTests over. There's now a very comprehensive set of browser-neutral tests being reviewed here.Great to see, thanks!On Tue, 20 Jun 2017 at 21:57 Mike West <[email protected]> wrote:I'm also enthusiastic about shipping this on Android! It fills a clear hole in the platform, and there's certainly developer interest. I have two questions about the effect on other platforms, one theoretical, one practical:1. I'm curious about the decision not to integrate with the OS-level sharing mechanism on desktop. Can you elaborate a bit on why you're limiting desktop sharing to webby targets in the future?The statement about not integrating with OS share systems is pragmatic (and can change). Both Windows and Mac have native sharing systems which we are happy to integrate with if it's feasible, but we haven't investigated either in much detail, and we don't want to block on it. (On Windows, for instance, it might not be feasible as it seems to require a UWP API which Chrome does not have access to).Got it, thanks. It seems like it would be worth our time to integrate with those platform-level features for parity with other native apps on those platforms, but I recognize that that's probably not the best use of your time right now. Perhaps it's something we could revisit when y'all get closer to shipping Web Share Targets?IMHO the main concern here is that the API is designed in such a way that it COULD in theory be integrated with the native sharing facilities (otherwise we risk never having interop with Edge and Safari, etc.). IIRC we have reason to believe the risk is low here, right Matt?
Yeah, this was designed with native system integrations in mind. Here is a doc from last year (I just updated it a bit):
I believe this will integrate with native systems on iOS, Mac and Windows without issues. It won't be able to take full advantage of all the features those systems have to offer, but it's a suitable lowest common denominator.
2. If you're only shipping on Android, do you plan to expose the API on desktop platforms? If so, I suppose `navigator.share()` would reject with an `AbortError`, based on https://wicg.github.io/web-share/#share-method? Does that give developers enough information to determine whether a call to `navigator.share()` could possibly succeed? Perhaps something like `NotSupportedError` would be appropriate in that case?Good question! No, we do not plan to have the share method exist on platforms that we have not rolled out the API. The API is designed such that you can use the presence or absence of the share method to determine whether share is likely to succeed (under the assumption that if share is supported on a given platform, there will always be at least one target, even if it's "Copy to Clipboard"). That's why we didn't add a dedicated method for feature detection.Ok. This is similar to the approach we've taken for things like WebBluetooth and `Notification.image`, so walking along that well-paved path seems reasonable, and makes feature-detection simpler, as you note.Agreed. We believe this is simpler for developers from a predictability perspective (since they almost always need to worry about whether a new feature is supported by the browser being used).(I'll admit that these platform-specific variances are pretty annoying when shipping new features, as it means that we need to update several platform-specific webexposed tests, but that's a reason to improve our tooling, not to expose potentially confusing no-ops to developers.)+1. This is a bug for the new feature control team which now owns this previously un-owned tooling :-)-mike
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-1UkL6qDOzhPyS99K6gbVX_9BT7gCq4NXm04%3Ds-SSHfg%40mail.gmail.com.
Matt Giuca
Jun 21, 2017, 8:13:37 PM6/21/17
to Rick Byers, Mike West, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther, [email protected]
That's 3 LTGMs, thanks.
+blink-api-owners-discuss for final approval as per https://www.chromium.org/blink/launching-features. Note that I am requesting approval for general-availability launch in M61.
Rick Byers
Jun 21, 2017, 8:27:48 PM6/21/17
to Matt Giuca, Mike West, Ben Wells, Owen Campbell-Moore, blink-dev, Sam McNally, Mike Lawther, blink-api-owners-discuss
No additional approval needed, you're ready to ship (that line says "if you are blocked on API owner LGTMs").
You will need an API OWNER to LGTM the change in virtual/stable/webexposed/ test results - feel free to ping me when the CL is up for review.
Rick
Reply all
Reply to author
Forward
0 new messages