There are various designs for a unified bookmark/share/etc menu floating around, part of which is implemented in activitystreams using socialapi share as the backend. It would be good to allow a way to have both web based and built-in share mechanisms that can be installed via webextensions. The idea with this experiment is to be able to install web based share providers via a web extension, I'll get into the benefits of that below. My experiment lets me add the following to a manifest: "share_action": { "share_target": "https://www.facebook.com/sharer/sharer.php?u=%{url}", // post_activation can probably go away "post_activation": "https://activations.cdn.mozilla.net/en-US/activated/facebook.html", // page_size is really only necessary for the panel-based implementation. "page_size": { "width": 700, "height": 400 } } Other elements used in the socialapi manifest are directly mapped to other elements in the webextension manifest (e.g. name, description), the above are the only unique manifest items used for share. I'm not certain about maintaining post_activation, it is a nice educational element, it may not be useful at this stage. From a product perspective, this doesn't immediately change anything. SocialAPI still handles the share panel, we can change out the UI as was done for activitystreams, etc. There is the potential to make the share_target url internal to the webextension, which would make it possible to have the ui contained in the extension. That might be interesting in some cases, but the web based share pages for the major services all already exist. We could also ship a default set via system addons. From a code/infrastructure perspective, this can simplify a lot. - the extensions can be distributed on AMO, whereas right now there is an entirely separate website (activations.mozilla.org) that exists solely for share. - the existing install [today in socialapi] is the same event based mechanism as lightweight themes, that support could be deprecated and removed - The "services" tab in the addon manager could be deprecated and removed - A bunch of addon manager related code in SocialAPI could be deprecated and removed - share_target url becomes "upgrade-able" by upgrading the webextension. Deprecating the above items would require some changes in SocialAPI to "upgrade" the users to the webextension version. There is a steady amount of traffic on share worth keeping. So it would be more work than just the webextension part (which was quite minimal). Aside from the upgrade support, there would be a sizable code reduction in SocialAPI.

Given the benefit and use of sharing, and the retirement of the Social API, this seems like a good idea. It makes it simpler to create sharing extensions, but needs some use case fleshing out around multiple sharing extensions and how Fx would handle that (one only, all, etc.).

There's nothing special to flesh out here, share is just a page action. If firefox frontend would like to treat share special, we can add some kind of flag on the page action that defines an "action type".

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958