Separate out failure modes for "no targets available" and cancellation/transmission error

[mgiuca]

Currently the share method throws an AbortError for three distinct failure modes:

• No share targets available.
• User cancelled picker.
• Error transmitting the data to the chosen target.

Lumping all three of these together (making them indistinguishable to the client) may not be sufficient. Consider an app that wants to use the following logic:

1. Call share.
2. If it fails before the user sees the picker (due to input error, not allowed to show a popup, or no share targets available), fall back to showing a hard-coded set of targets (like Twitter and Facebook).
3. If it fails after the user sees the picker (due to cancellation, or error transmitting the data), do nothing. Perhaps show an error message if there was an error transmitting the data, but not if the user cancelled the picker.

It is not currently possible to distinguish these cases. It seems the most important thing to distinguish is whether it failed before or after the user saw the picker. Secondarily, we might want to distinguish user cancellation and transmission error.

Should we perhaps change to reject with a different error type in each case? Or somehow attach additional data to the rejection object.

[marcoscaceres]

@mgiuca, do you still think this is something we should pursue? The situation you describe makes sense, but I'm not sure it comes up often enough in practice: i.e., browsers + OS seem to fairly reliably show a picker.

[marcoscaceres]

I'm going ahead and closing this as this hasn't come up as an issue in practice.

[ewilligers]

Thanks for closing.

If this gets reconsidered in future, we will need to make sure not to expose to the developer whether there are share targets available. Implementations would also need to avoid making private browsing modes detectable, in any implementations where some/all shares are blocked in such modes.