Intent to Implement: Web Share Target API

[Matt Giuca]

Contact emails

{mgiuca,sammc,benwells,owencm}@chromium.org, const...@google.com

Spec

https://github.com/WICG/web-share-target/blob/master/docs/interface.md

Design doc:

https://docs.google.com/a/chromium.org/document/d/19E6s2m18uL87BqgQdr773GMfdr5Os40aw4asbh0xxrY/edit

Summary

When the user shares data (text, URLs, images) from native applications or web sites via the Web Share API [1], the proposed Web Share Target API [2] will allow sites to be displayed as options to receive the shared data, instead of only native applications.

This builds on the ongoing work with Web Share, currently available as an Origin Trial from Chrome 55 to 57, which allows a website to initiate a share. Developers commonly request the ability to be a share target, whenever we publicly talk about Web Share [3, 4].

We plan to make participating sites become “registered” as share handlers when they are installed (add-to-desktop, add-to-shelf or add-to-home-screen). In the Desktop version, we will show an app picker when Web Share is used. In the Android version, we will insert the registered sites dynamically into the system intent picker.

The majority of implementation changes will be UI related and not affected by standards, with the exception of metadata added to the web app manifest, which sites need to provide in order to participate.

[1] https://github.com/WICG/web-share

[2] https://github.com/WICG/web-share-target

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=620973#c13

[4] http://stackoverflow.com/questions/38189160/can-a-progressive-web-app-be-registered-as-a-share-option-in-android

Motivation

Progressive Web Apps [5] are websites that exhibit behaviours of native applications, such as offline capabilities. One missing feature is the ability to receive shared data, such as URLs. The user can share text and URLs from any application to any native social networking, mail, or chat app on Android (for example). A similar app for the web cannot interoperate with the share system, instead requiring the user to manually copy, launch the app, and paste. (This manual approach often leads to non-canonical URLs being shared, such as mobile-specific URLs or detritus query/fragment, which can be avoided with a dedicated Share API.)

The Web Share Target API fills that gap, allowing installed web apps to be targeted with a single tap. On some platforms, Web Share Target is required to bootstrap the Web Share ecosystem if there are no native share targets.

[5] https://developers.google.com/web/progressive-web-apps/

Interoperability and Compatibility Risk

Since Web Share Target is an entirely passive API, there is minimal compatibility risk. There are no methods that sites will be calling which may be absent on non-conforming browsers. It’s just a manifest attribute that may be ignored by non-conforming browsers.

If we later decide to un-ship this feature, it will stop working, but it won’t break any sites.

No public support from other browser vendors but have had some private discussions with Mozilla and we were encouraged to switch to an API closer to Mozilla’s Social API [6], which should simplify the interop with Firefox.

We intend to run an Origin Trial [7] once the initial implementation is complete to allow us to assess the API design. We are not yet announcing an intent to ship.

[6] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Social_API/Manifest

[7] https://github.com/jpchase/OriginTrials

Ongoing technical constraints

Parts of the Web Share Target implementation would assume certain OS-specific features such as Android intents. However, the API specification will not be Android-specific, and the web-to-web sharing system will be common to all platforms.

This API will introduce new UI surfaces on some platforms (for the picker UI) which represents an ongoing surface area and implementations across multiple platforms.

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

Eventually, but since this requires platform-specific UI, we will start with toolkit-views on Desktop (Windows, Linux and Chrome OS) and proceed from there.

This will also necessitate extending the existing implementation of Web Share (currently Android-only) to Desktop (since Web Share Target on Desktop can only receive shares from other websites).

OWP launch tracking bug

https://crbug.com/668389

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5662315307335680

Requesting approval to ship?

No.

[Mounir Lamouri]

This is great to see some work happening in this space. As a user, it is
a main pain point that I have to copy-paste urls when I want to share
something over my added to homescreen email client.

Looking at the current proposal, I am surprised to see that only a
boolean will be added to the manifest. Shouldn't the Manifest be aware
of the type of data that the application can handle? I believe that it's
possible to share a lot of different things and if we want web
applications to participate in the native share intent UI, we should
make sure they do not appear all the time but only when they will do
something with the information they received. How do you plan to handle
this?

-- Mounir

On Thu, 8 Dec 2016, at 06:09, Matt Giuca wrote:
> *Contact emails*
> {mgiuca,sammc,benwells,owencm}@chromium.org, const...@google.com
>
> *Spec*
> https://github.com/WICG/web-share-target/blob/master/docs/interface.md
>
> *Design doc:*
> https://docs.google.com/a/chromium.org/document/d/19E6s2m18uL87BqgQdr773GMfdr5Os40aw4asbh0xxrY/edit
>
> *Summary*

> *Motivation*

> Progressive Web Apps [5] are websites that exhibit behaviours of native
> applications, such as offline capabilities. One missing feature is the
> ability to receive shared data, such as URLs. The user can share text and
> URLs from any application to any native social networking, mail, or chat
> app on Android (for example). A similar app for the web cannot
> interoperate
> with the share system, instead requiring the user to manually copy,
> launch
> the app, and paste. (This manual approach often leads to non-canonical
> URLs
> being shared, such as mobile-specific URLs or detritus query/fragment,
> which can be avoided with a dedicated Share API.)
>
> The Web Share Target API fills that gap, allowing installed web apps to
> be
> targeted with a single tap. On some platforms, Web Share Target is
> required
> to bootstrap the Web Share ecosystem if there are no native share
> targets.
>
> [5] https://developers.google.com/web/progressive-web-apps/
>

> *Interoperability and Compatibility Risk*

> Since Web Share Target is an entirely passive API, there is minimal
> compatibility risk. There are no methods that sites will be calling which
> may be absent on non-conforming browsers. It’s just a manifest attribute
> that may be ignored by non-conforming browsers.
>
> If we later decide to un-ship this feature, it will stop working, but it
> won’t break any sites.
>
> No public support from other browser vendors but have had some private
> discussions with Mozilla and we were encouraged to switch to an API
> closer
> to Mozilla’s Social API [6], which should simplify the interop with
> Firefox.
>
> We intend to run an Origin Trial [7] once the initial implementation is
> complete to allow us to assess the API design. We are not yet announcing
> an
> intent to ship.
>
> [6]
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Social_API/Manifest
> [7] https://github.com/jpchase/OriginTrials
>

> *Ongoing technical constraints*

> Parts of the Web Share Target implementation would assume certain
> OS-specific features such as Android intents. However, the API
> specification will not be Android-specific, and the web-to-web sharing
> system will be common to all platforms.
>
> This API will introduce new UI surfaces on some platforms (for the picker
> UI) which represents an ongoing surface area and implementations across
> multiple platforms.
>

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

> Eventually, but since this requires platform-specific UI, we will start
> with toolkit-views on Desktop (Windows, Linux and Chrome OS) and proceed
> from there.
>
> This will also necessitate extending the existing implementation of Web
> Share (currently Android-only) to Desktop (since Web Share Target on
> Desktop can only receive shares from other websites).
>

> *OWP launch tracking bug*
> https://crbug.com/668389
>
> *Link to entry on the feature dashboard*
> https://www.chromestatus.com/features/5662315307335680
>
> *Requesting approval to ship?*
> No.
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev...@chromium.org.

[Matt Giuca]

On Sat, 10 Dec 2016 at 22:24 Mounir Lamouri <mou...@lamouri.fr> wrote:

This is great to see some work happening in this space. As a user, it is
a main pain point that I have to copy-paste urls when I want to share
something over my added to homescreen email client.

Looking at the current proposal, I am surprised to see that only a
boolean will be added to the manifest.

The proposal on GitHub is unfortunately a bit out of date. For a better idea of our current plan, please see Connie's design doc (also linked from the above email):

https://docs.google.com/document/u/1/d/19E6s2m18uL87BqgQdr773GMfdr5Os40aw4asbh0xxrY/edit

 

Shouldn't the Manifest be aware
of the type of data that the application can handle? I believe that it's
possible to share a lot of different things and if we want web
applications to participate in the native share intent UI, we should
make sure they do not appear all the time but only when they will do
something with the information they received. How do you plan to handle
this?

The thing is the scope is currently so limited that we didn't see any real distinction between what targets can receive: pretty much we're just looking at apps that can receive a bit of text and/or a URL. On Android there isn't even a distinction between those two things (URLs are just text that happens to match a certain regex). So at the moment there's just "apps that can receive shares" and those that can't.

I agree we should leave it expandable to this in the future so we probably should have a dictionary for share target metadata (not just a Boolean) regardless.

[Matt Giuca]

An update: we have been talking to the Web APK team (Yaron and Peter) about implementing Web Share Target on Android, and they have a working prototype.

This will mean that Web APKs (i.e., progressive web apps that are added to home screen on Android) for sites with a manifest that has a share_target member, will have an equivalent entry in their Android manifest, and will appear in the Android intent picker once installed.

We are planning to roll this out to Canary and Dev channel (possibly in M64 or M65), and I don't believe we need any approval for this because it won't roll out to stable. No immediate plans to roll this to stable until further testing and standards work. Consider this an updated intent to implement for Android.

Also, I have written a draft spec for Web Share Target:

https://wicg.github.io/web-share-target/

I will be sending this through to a TAG review after addressing some of the issues noted there.

[Yuto Tokunaga]

Hi folks.

I've been working to implement Web Share Target to mastodon (#5850). I noticed that the APK which is downloaded to my Android by Finsky when I do "Add to home screen" is not updated after updating manifest.json on my site. Please see below for detail.

1. Add "share_target" member to manifest.json.
   
2. Reload Chrome and do "Add to home screen".
   
3. Notice that I'd written a wrong URL to "url_template" field.
   
4. Update "url_template" field in manifest.json.
   
5. Uninstall the Web APK.
   
6. Reload Chrome and do "Add to home screen".
   
7. Android share functionary still opens the wrong URL when I choose the app in the intent picker.

I've tested by Chrome Canary 65.0.3301.0. I've checked AndroidManifest.xml of downloaded APK and confirmed that the Activity for share points to the wrong URL.

Finsky should download updated APK when I do "Add to home screen" after updating manifest.json on the site.

Regards,
Tokunaga

[yunta...@gmail.com]

[Dominick Ng]

Hi Tokunaga,

WebAPK updating based on changes to Web Share Targets is in progress and has not yet been completed. Please follow crbug.com/761007 for updates. Specifically, the functionality to detect a changed share target URL and update because of that is not yet ready.

As a workaround, please try changing any other field in the manifest (e.g. the name or short name), and then adding the site to home screen again. This should trigger an update of the WebAPK, which will hopefully include the new share template.

In future, please file a bug on crbug.com rather than respond to these intent threads with issues. :)

--
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/37b65e7f-34af-4fda-8556-e449df7ee382%40chromium.org.

[Yuto Tokunaga]

Hi Dominick,

Thank you for replying. 

As a workaround, please try changing any other field in the manifest (e.g. the name or short name), and then adding the site to home screen again. This should trigger an update of the WebAPK, which will hopefully include the new share template.

Thank you for helpful advice. I'll try this method later.

 In future, please file a bug on crbug.com rather than respond to these intent threads with issues. :)

Noted with thanks.

Regards,

Tokunaga