Script abortable shares

[marcoscaceres]

It might be useful to allow web sharing to be aborted by via script. For instance, the thing being shared might no longer be valid. As such, should we consider adding support for an abort signal?

[mgiuca]

I don't think we should (or even can, at least on Android) support this.

If we could implement it, the user experience would be that you see a share dialog, and suddenly it disappears because the sharing site decides to revoke the share. That would be very jarring.

In terms of the data model, what does "the thing being shared might no longer be valid" mean? You are sharing a piece of data, not a handle on the data, so we just consider that at the time of the call to share(), that data is no longer under control of the site; it's "owned" by the UA or OS.

If the data can become invalid (like perhaps the URL points at a page that no longer exists), you don't have any opportunity to revoke it once the user completes the share (like, it becomes permanently part of a tweet), so I don't see why we need the ability to revoke it during the (typically) few seconds that the user is considering what target to share to.

[marcoscaceres]

If we could implement it, the user experience would be that you see a share dialog, and suddenly it disappears because the sharing site decides to revoke the share. That would be very jarring.

Agree, could this happen regardless? presumedly, if the underlying page navigates while the share UI is being shown, the UI would be shut down.

so I don't see why we need the ability to revoke it during the (typically) few seconds that the user is considering what target to share to.

I agree, the use case is a bit far fetched :) I ran into this as a corner case of #113, where I want to programmatically cancel the share because I only care that multiple calls to share() returned rejected promises.

[mgiuca]

Agree, could this happen regardless? presumedly, if the underlying page navigates while the share UI is being shown, the UI would be shut down.

I don't see why that would necessarily happen. It could be at the UA's discretion, but you could also imagine that the page navigates while the picker still remains on screen (as it would on Android, because the picker is being controlled by the operating system). (And then the promise never resolves because the context has been destroyed, but the data can still be delivered.)

You could also say the device could run out of power while the picker is being displayed. This is outside of the spec because it's been sent out of the web ecosystem into the picker.

I think this is not something we want to give site control over, so I'll close it.

[marcoscaceres]

ok, we should probably pick up the navigation issue in another bug tho.

[mgiuca]

Which issue? Why does the spec need to care what happens if the page navigates while a picker is being displayed?

[marcoscaceres]

Which issue? Why does the spec need to care what happens if the page navigates while a picker is being displayed?

Absolutely! let's pick this up in #120