Support multiple share targets

[mgiuca]

The current spec only allows a single share target (which implicitly takes the name of the app). Discussed here on Chromium.

I was planning to not support this initially and see if there is demand for it. We should ensure we can extend the API to support multiple share targets later.

Allowing multiple share targets introduces significant complexity:

• You need to allow for more than one in the manifest (that part is easy, and we can extend into it later).
• You need to deal with the fact that different platforms will support a different maximum number of share targets, and provide some way for apps to prioritize them and deal with the fact that some may be missing.
• You need to provide additional meta-data such as a name, and possibly icon, for each share target.
• You need to deal with the spoofing concern of apps naming their share targets after some other app. (Whereas if we have only one share target named after the app, we would always show the installed name of the app which the user got to see when they installed it.)

So I would like to just have a single share target for now, with the option of extending later. We can extend it by making the share_target member be a ShareTarget or sequence<ShareTarget> in IDL, allowing developers to either specify a single target or multiple, and adding an optional "name" attribute to ShareTarget.

[kenchris]

Could you create a "Feature Request" label or similar and attach to these issues you don't intent to solve for the first release?

[mgiuca]

I'll use the built-in "enhancement" label. Thanks for the suggestion.

[PaulKinlan]

Just looping back on this - has this been considered yet? I already have a simple app that needs to accept a GET and POST action separately.

[mgiuca]

@ericwilligers

I'm still concerned that this creates a wide surface for spoofing, for fairly small benefit.

Why do you need two separate GET/POST actions? Do you want them both to show up at the same time in the intent picker? Why not just make it a POST action?

[PaulKinlan]

If I am Twitter I might want to share just a link and text using my existing URL structure (they have a 'web intent' url for sharing), and post images via the POST method to an existing form.

If I have just one POST for my entire App it and I wanted to offer a share URL or Share Image function then using params object I would be forced to define a file so I could handle the image share, which means that because it is present in the configuration there must be a file present on the invocation (and thus my simple case of link sharing wont work) likewise in actual Android impl it will have intent-filter to accept a file, which actually means the user can never share a URL and have the app be matched.

The TL;DR - for many apps they are going to want to have more than one way of sharing to it, and they will not want to have multiple PWA's just so that you can share to two different end points, For my blog, I have to have two directories for link sharing and image sharing and the lack of ability to have multiple target configurations in the manifest means that I can't have different options

https://paul.kinlan.me/share/image/manifest.json
https://paul.kinlan.me/share/link/manifest.json

Right now I don't need to always share a file, but the API forces me to make them separate Apps which is ok for me, but won't be for the bigger apps.

Selfishly for simple sharing, I would like to do a GET because I can make bookmarks, but still have the option to do a POST for more complex interactions.

A further issue is that you can't name targets/actions. On Android it takes the apps (short_name?) and names that they share target, but the Twitter Native app has Share URL, Share Image to public timeline and Share anything to DM. So in the future it would be useful to name actions if we have more than one.

I do undertstand the worry of increasing surface areas, but a lot of Android apps do have many entry points for ranges of files types (which we can do if we mirror input type=file's accept attributes). For the simple case, alllowing only a single GET and a single POST might be a temporary solution... ?

[EtienneBruines]

To continue this discussion from a web-programmer point-of-view: I can imagine communication-apps to want to expose multiple targets, for the favorite contacts or most-used groups.

Doing this through the manifest.json could work, if multiple targets were allowed.

• An optional name attribute would be nice
• Prioritizing might be done through the order in which they appear in the manifest.json? Then the prioritizing is left to the app.

The question becomes though, is this more like "Add to Dropbox" vs "Share with Dropbox", or would this also support "Share via John Doe", where my app supplied the "John Doe" part? (Using Android as an example here) How should this second example be handled differently?

[ANSB]

Agree with this feature. Actually I'm working on a PWA which send an adress to google maps and, using share targer, get back the location. But my PWA as a "new.html" page with this feature (so I register new.html as the targer in the manifest, but I'm also an "edit.html" page with the same feature....
What I plan to to is use POST rather than GET in order to no trigger directly the JS of the target, but the fetch event of the sw.js file, try to detect which page is opened (new or edit) and send the data as a message.... A bit complicated.
I suggest such an extend:
action -> simple name of HTML is only on target; array of name if mutiple (will not break comptibility)
action_name -> array of name shown to the user for selection. So if I set "Create" and "Edit" when my action i set to "new.html" and "edit.html" and my App is "BestApp" the user will see "BestApp - Create" and "BestApp - Edit".
If array of action exist but not array of name, file name in action will be used.
Notice one BIG problem with share target using sw.js: as soon at the fetch is trigged, the sw load the dest page. So if you are on "new" and set target to "edit", as soon as the fetch is received, sw will open "edit" and try to comunicate with it. Of edit is not opened faster enought, the comuniction message is lost. Only two example on the web for sharing images with PWA. Two works fine if PWA as only ONE page and receive ONE image. Both fail in other cases....

[m-lautenbach]

Any updates on this? Working on an app that accepts images, but images are often shared as links.
At least a way to support all kinds of share targets once each would be great.

[ewilligers]

A concern is that criminals might create a "Cute Puppies" PWA with a puppy icon, but then declare various share targets like "Add to Dropbox" and "Share with Dropbox", with Dropbox icons. Users might think they are sharing to Dropbox, when they are actually sending their files to the criminals behind the "Cute Puppies" PWA.

Working on an app that accepts images, but images are often shared as links.

This use case can be supported by a single share target, that accepts text, urls and image files.

[EtienneBruines]

A concern is that criminals might create a "Cute Puppies" PWA with a puppy icon, but then declare various share targets like "Add to Dropbox" and "Share with Dropbox", with Dropbox icons. Users might think they are sharing to Dropbox, when they are actually sending their files to the criminals behind the "Cute Puppies" PWA.

Can´t this already be "achieved" with a single target?

At the moment, native apps have the same (security) issue.

Their way of handling the "subtargets" (i.e. contacts from WhatsApp) is by adding the app-icon of the App on top of the icon of the contact. How it is then displayed, would be up to the OS. The OS could potentially enhance the experience by (when you click on it) show the app-icon with the domain name or URL full-screen for about a second or two. IMHO the spec could describe such countermeasures but should not spec/require/enforce them, as I feel it might be rather out of scope because it goes into how the OS displays the share targets.

[m-lautenbach]

This use case can be supported by a single share target, that accepts text, urls and image files.

From the documentation and example apps, this didn't seem possible. I'll give it a try, thanks.

[SahilAggarwal2004]

Any updates on this?