[SPIKE] Consider using native share sheet vs custom share sheet

[vesta0]

Goal: Investigate and discuss whether we want to use native share sheet vs custom share sheet

Acceptance criteria:

1. I can share a link to my other installed apps
2. I can copy a link to clipboard
3. I see a list of my most frequently used apps first Add 'n' recently used apps to share sheet #4231
4. When signed into my FxA, I can send a tab to other FxA connected devices
5. I see a list of my other FxA connected devices
6. When not signed into FxA, I see an icon/option directing me to sign in
7. When Add action states to share sheet Add action states to share sheet #2897
8. When sharing a tab, I can see a thumbnail or the tab I am sharing Add tab cards to share sheet #2754

Product preference:

Using the custom share sheet because:

• More flexibility going forward
• I believe we may not be able to cover requirement Add README with taskcluster badge. #6 (and Issue #1: Keep build reports as artifacts. #7) using the native share sheet. This is a great opportunity to remind users about sync and its usefulness. See here for share sheet today: https://analytics.amplitude.com/mozilla-corp/chart/zy255ur

Original conversation: #2819

Other related bugs and feature requests to consider

• [Bug] Sharing multiple tabs to another browser, only opens 1 tab #4178
• share menu improvements #3861
• Quick share #3726
• Send tab to device without opening the browser #1523
• When sharing a page, the page title is not shared, only URL #4021
• Feature request: don't push 'send to device' icons up when populating share menu #4528

Will likely impact other bugs with the Feature:ShareSheet label

┆Issue is synchronized with this Jira Task

[liuche]

This bug should be timeboxed to explore native share sheet and what of the linked issues/requirements it can accomplish.

Specifically, we MUST be able to add Send Tab.
If that's possible, then use the native sharesheet.

[jonalmeida]

Specifically, we MUST be able to add Send Tab.

Surfacing when an account isn't signed in (for enabling send tab) is also important.

[liuche]

Vesta will update acceptance criteria to include what the Required share sheet items are + Deliverable. If possible, can size each Requirement.

[vesta0]

@liuche I have updated the description of this issue with the acceptance criteria and the product and UX preference. Please feel free to move on to eng investigation/validation and sizing.

FYI this may be a good issue for @jonalmeida to pick up since he worked on it before.

[liuche]

@jonalmeida if you want to pick this up, feel free to (but please comment/assign, so we don't duplicate work!)

[jonalmeida]

Adding it to the a-c triage for next week since we already have a full sprint right now. Feel free to grab this if I don't get to it by then.

Thanks for the detailed acceptance criteria Vesta!

[vesta0]

@jonalmeida it would be great to know status of this investigation by end of day today, so we can add the relevant bugs to our next sprint at tomorrow's sprint planning. Let me know if that's possible.

[jonalmeida]

The native share sheet with Direct Share has advantages for ease of implementation, provides sorting of apps and shareable contacts.

The limitations for it however, is that we aren't able to show users that they need to sign into a Sync account (req 6) in order to leverage it or show error states when an account needs to be (re-)authenticated (req 7). The biggest disadvantage is that we can no longer iterate on top of the native share sheet to show the tabs or collections (req 8) that we want to share, or in the future adding "nearby devices" to the sheet.

This seems like a similar strategy other apps with custom share sheets are also taking as well (e.g. Google Photos, Google Maps, Youtube, Spotify). A future consideration to make, is to separate device sharing with sharing links (similar to Instagram) to apps but adds complex user flows that we need to investigate more into.

On the technical side, using direct share with the ShortcutManagerCompat currently wouldn't work well since we do not persist shareable devices and need to consider how we want to query for new ones and invalid old ones that may no longer be available. This would be useful though when trying to share to your other devices from another app (see #1523).

For #4528, we can definitely consider following the suggestion, but I think it would be up to UX to decide on it.

There is also a theme from the linked issues that we can resolve: implement recently shared apps (#4231). This should remove a lot of the pain-points that seem to be mentioned which other custom share sheets have that we currently do not.

TL;DR version: using the native share sheet is NOT recommended for the requirements we want to fulfill. Fix the recently shared apps bug to solve a majority of the issues that users are facing instead.

[IndefiniteBen]

Is it possible to have a button in the custom share sheet that opens the native one? Or is that use case considered covered by long pressing a link and using "share link" on the pop-up?