Web Share Target

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Share Target
• Specification or proposal URL: https://wicg.github.io/web-share-target/
• Mozillians who can provide input (optional): @tantek @NotWoods

Other information

An API that allows websites to declare themselves as web share targets, which can receive shared content from either the Web Share API (see #27), or system events (e.g., shares from native apps).

cc @mgiuca

[marcoscaceres]

As we are pretty much done with prototyping Web Share, we'd like to begin prototyping this feature in Fenix.

mozilla-mobile/fenix#5783

I've updated #183 to reflect that.

[marcoscaceres]

Intent to prototype on dev-platform.

[dbaron]

FWIW, there might be a little material of interest in w3ctag/design-reviews#221.

[dbaron]

@marcoscaceres So given the intent, I assume you'd give this a worth prototyping position?

During the TAG review I think I was reasonably happy about where this spec ended up; the connection to existing form submission mechanisms seems to avoid a lot of the potential complexity.

One thing I realized, after a more recent discussion about app manifests -- is it OK for an API to be exposed only through Web App Manifest, or are Web App Manifests intended to be syntactic sugar for features that are also available elsewhere? (But manifests may in some cases allow the features to be available for a page the user hasn't actually opened yet.) In other words, should there also be some sort of explicit registration/unregistration API for this as well?

[marcoscaceres]

@marcoscaceres So given the intent, I assume you'd give this a worth prototyping position?

Yes, that would be great.

One thing I realized, after a more recent discussion about app manifests -- is it OK for an API to be exposed only through Web App Manifest, or are Web App Manifests intended to be syntactic sugar for features that are also available elsewhere?

I think this is something we need to figure out more broadly for the Web. "Installing" a web application shouldn't necessarily enable this capability for free. For Share, there is still a user action involved in selecting a share target from the share sheet or share context-menu.

In other words, should there also be some sort of explicit registration/unregistration API for this as well?

As above - something we need to explore. For some potentially non-harmful features, maybe not because the user has gone through an installation ceremony. But with others yes, like (hypothetically) with something like Payment Handlers: it may signal that it's a "payment handler" via web manifest, but still require an explicit permission grant from the user to handle payments.

[marcoscaceres]

I'm hoping we can close this one too with "worth prototyping", but I'm a bit unsure what to put in the position details. @dbaron, any suggestions?

[andreasbovens]

Here's a vote for "worth prototyping".