Intent to Ship: Web Share API (Windows & Chrome OS)

[Eric Willigers]

Contact emails

mho...@microsoft.com, ericwi...@chromium.org

(mhochk is addressing the Windows portion, ericwilligers the Chrome OS portion)

 

Explainer

https://github.com/w3c/web-share/blob/master/docs/explainer.md

 

 

Spec

https://w3c.github.io/web-share/level-2/

 

Level 1 support already received a TAG review (https://github.com/w3ctag/design-reviews/issues/170, https://github.com/w3ctag/design-reviews/issues/179) and Level 2 was discussed in the TAG review for Share Target (https://github.com/w3ctag/design-reviews/issues/221).

 

See also the pre-existing Android-specific Intent To Ship for Level 1 (https://groups.google.com/a/chromium.org/d/msg/blink-dev/nwmTLZKFFIA/8bslfL3JAwAJ) and Level 2 (https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cr7Jrb9XMgE/lja4PhCtBgAJ).

 

 

Summary

Web Share is an API set for sharing data (text, URLs, files) from a web app (to which the data is already available) to an app of the user's choosing.  This has already been implemented/shipped in Chromium for Android and has been implemented/shipped in Edge for Windows.  This phase covers extending the support for these APIs to the Windows and Chrome OS implementation in Chromium.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/PZkIB8wBTwQ/qfX1At8UAgAJ

 

Motivation

The ability to invoke a platform "share" event is already exposed to websites today as a platform-neutral API and its usage is growing, but is only supported on some platforms.  To better allow websites to take advantage of this functionality this will extend the support to include more platforms.

 

The underlying Web Share API's motivations focuses around existing scenarios where websites offer the ability to "share", but are forced to do so using individual links to developer-selected targets.  This not only requires the site author to individually add support for targets, it also limits those targets to other websites (not native apps) and limits the user's selection options to those chosen by the site author.

 

Risks

Interoperability and Compatibility

Interest in this feature has been consistently expressed, but even with its growing support we expect most sites to offer this functionality as an opportunistic addition to their pre-existing share functionality.  As such, the impact on sites of adding (or removing) support on an additional platform should be minimal.

 

Edge: Shipped Level 1 and 2 on Windows.

Firefox: Partially implemented and continuing development (bug, bug)

Safari: Shipped Level 1 support (bug) and continuing development of Level 2 support (bug)

Web / Framework developers: The ability to share images and files has been a consistent request.

 

See also the Intent to Implement: Web Share API (Android) discussion: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/1BOhy5av8MQ/OPPt76oZCQAJ

See also the Intent to Implement: Web Share Level 2 (Android) discussion: https://groups.google.com/a/chromium.org/forum/#%21msg/blink-dev/AiKgWvv3cq0/xAsjfSfMDQAJ

 

Ergonomics

The Web Share Target API complements this API. Web applications can register to receive share requests. It is shipped in Chrome for Android (https://web.dev/web-share-target/) and implemented (not shipped) in Edge for Windows. Separate Intents will cover Web Share Target API for Chrome OS.

 

Activation

The API is straightforward and feature detectable.  Developers should be able to make use of it immediately without degrading the experience of users running older browsers.

 

Debuggability

No DevTools changes are required.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No.  This feature is already implemented on Android and this will extend the feature support to include Windows and Chrome OS.  Web Share has to be specifically implemented for each platform because it is an OS interop mechanism.

 

Link to entry on the feature dashboard

Level 1: https://www.chromestatus.com/feature/5668769141620736

Level 2: https://www.chromestatus.com/feature/4777349178458112

Windows Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1035527

Chrome Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1110119

 

Tutorial / Demo links

https://web.dev/web-share/

https://w3c.github.io/web-share/demos/share-files.html

https://github.com/GoogleChrome/samples/tree/gh-pages/web-share

[Manuel Rego Casasnovas]

This is just shipping on more platforms (and catching up with other
implementations) so it doesn't look risky.

But I have a question as tests are not mentioned at all on the intent
and they're part of the template.
Are there any WPT tests regarding this, so we can ensure some
interoperability level between the different implementations?

Thanks,
Rego

On 08/09/2020 05:39, Eric Willigers wrote:
> Contact emails
>
> mho...@microsoft.com, ericwi...@chromium.org
>
> (mhochk is addressing the Windows portion, ericwilligers the Chrome OS
> portion)
>
>  
>
> Explainer
>
> https://github.com/w3c/web-share/blob/master/docs/explainer.md
>
>  
>
>  
>
> Spec
>
> https://w3c.github.io/web-share/level-2/
>
>  
>
> Level 1 support already received a TAG review
> (https://github.com/w3ctag/design-reviews/issues/170,

> https://github.com/w3ctag/design-reviews/issues/179)and Level 2 was

> discussed in the TAG review for Share

> Target(https://github.com/w3ctag/design-reviews/issues/221).

>
>  
>
> See also the pre-existing Android-specific Intent To Ship for Level 1
> (https://groups.google.com/a/chromium.org/d/msg/blink-dev/nwmTLZKFFIA/8bslfL3JAwAJ)and
> Level

> 2(https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cr7Jrb9XMgE/lja4PhCtBgAJ).

>
>  
>
>  
>
> Summary
>
> Web Share is an API set for sharing data (text, URLs, files) from a web
> app (to which the data is already available) to an app of the user's
> choosing.  This has already been implemented/shipped in Chromium for
> Android and has been implemented/shipped in Edge for Windows.  This
> phase covers extending the support for these APIs to the Windows and
> Chrome OS implementation in Chromium.
>
>  
>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/PZkIB8wBTwQ/qfX1At8UAgAJ
>
>  
>
> Motivation
>
> The ability to invoke a platform "share" event is already exposed to
> websites today as a platform-neutral API and its usage

> <https://www.chromestatus.com/metrics/feature/timeline/popularity/1501>is growing,

> but is only supported on some platforms.  To better allow websites to
> take advantage of this functionality this will extend the support to
> include more platforms.
>
>  
>
> The underlying Web Share API's motivations focuses around existing
> scenarios where websites offer the ability to "share", but are forced to
> do so using individual links to developer-selected targets.  This not
> only requires the site author to individually add support for targets,
> it also limits those targets to other websites (not native apps) and
> limits the user's selection options to those chosen by the site author.
>
>  
>
> Risks
>
> Interoperability and Compatibility
>
> Interest in this feature has been consistently expressed, but even with
> its growing support we expect most sites to offer this functionality as
> an opportunistic addition to their pre-existing share functionality.  As
> such, the impact on sites of adding (or removing) support on an
> additional platform should be minimal.
>
>  
>
> Edge: Shipped Level 1 and 2 on Windows.
>
> Firefox: Partially implemented and continuing development (bug

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1402369>, bug
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1641280>)

>
> Safari: Shipped Level 1 support (bug

> <https://bugs.webkit.org/show_bug.cgi?id=171100>) and continuing

> development of Level 2 support (bug

> <https://bugs.webkit.org/show_bug.cgi?id=198606>)

>
> Web / Framework developers: The ability to share images and files has
> been a consistent request.
>
>  
>
> See also the Intent to Implement: Web Share API (Android) discussion:
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/1BOhy5av8MQ/OPPt76oZCQAJ
>
> See also the Intent to Implement: Web Share Level 2 (Android)
> discussion:
> https://groups.google.com/a/chromium.org/forum/#%21msg/blink-dev/AiKgWvv3cq0/xAsjfSfMDQAJ
>
>  
>
> Ergonomics
>
> The Web Share Target API

> <https://w3c.github.io/web-share-target/level-2/>complements this API.

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2798443b-6cae-4502-bfd6-f79c606921b9o%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2798443b-6cae-4502-bfd6-f79c606921b9o%40chromium.org?utm_medium=email&utm_source=footer>.

[Eric Willigers]

There are WPTs for failure scenarios: invalid arguments, lack of permission.

There are only manual WPTs for the success scenarios as they involve operating-system-specific share sheets, and external applications to receive share requests.

[Daniel Bratell]

LGTM1

Nice seeing more parity between platforms!

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f822c1f6-8f8c-4e6c-aee5-e07b420c937bn%40chromium.org.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e416c884-a66f-a320-80a0-d5adacb337d3%40gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhNQvL1TepT4Gukr12b-c_xsDAVVnLP9Vr_TyJ_f8Z_9w%40mail.gmail.com.

[Theodore Olsauskas-Warren]

Continuing discussion from intent to implement. I think it valuable to invoke Google's core sharing tenets when thinking about the specification. I'd argue there's room for improvement before simply implicitly abdicating the responsibility to the UA. Briefly the relevant core sharing tenets are:

• The user should know which identity will be exposed through sharing.
  
• The user should know what information will be shared.
  
• The user should know with whom the information will be shared.

These are not browser specific tenets, but they're valuable nevertheless. The spec does a good job satisfying the last tenet: "requirement that navigator.share() presents the user with a dialog asking them to select a target application", and for technical reasons (stenography etc) satisfying the first is probably infeasible, but including a requirement to inform the user of what will be shared seems like a desirable improvement. Conveying a deep understanding of what will be shared is probably not feasible (again for technical reasons) but surely some effort should be required e.g. displaying the image, listing the files, showing the URL or text, or warning when the data is otherwise intractable.

As a thought experiment, do you think an implementation of the spec which makes no attempt to inform the user of what will be shared is a [valid, good, useful] implementation? If it's expected that all the implementations will attempt to inform the user of what they are sharing in some way, it seems worthwhile to include this in the spec.

[Eric Willigers]

>  If it's expected that all the implementations will attempt to inform the user of what they are sharing in some way, it seems worthwhile to include this in the spec.

It is anticipated that browsers will rely on the host operating system's sharing or intent system. This is why we don't mention usual web platform accessibility principles for the user interface - browsers are likely to have no control - and instead mention following OS level accessibility guidelines. 

Android's Intent system simply shows the list of available targets, not what is being shared. We aim to ensure web apps can be compatible with native apps in terms of user experience, and so don't mandate an extra dialog.

[Hassan Talat]

Hi all,

I'd like to 'share' an update that WebShare API on macOS has been approved for shipping in m128.