Should share() be allowed to resolve immediately?

[saschanaz]

Windows currently does not support a way to track share action consistently: https://bugzilla.mozilla.org/show_bug.cgi?id=1641280

Currently a caveat is that there is still no way to track selection of "Copy Link" feature, and doing so currently creates a promise that will never be resolved.

Edge team somehow decided to immediate resolve the promise regardless of what actually happens with the share data on Windows (at least since Edge 85) and never throw when canceled, but the spec says resolving should happen only after successful transmission:

Once the data has been successfully transmitted to the target, resolve [[sharePromise]] with undefined.

Should we revise the spec to allow Edge behavior?

[marcoscaceres]

That behavior doesn't sound great, tbh. Developers would get zero feedback. We should see if the Windows folks are willing to fix their API.

[saschanaz]

So far Twitter and YouTube are not using the result of the promise, that's probably why Edge team went that way. I'll try ping some relevant person at Microsoft.

[ewilligers]

The spec could gain a disclaimer paragraph, for platforms where it is not possible to distinguish cases 11.3, 11.5 and 11.6.

I don't see a reason to hold off shipping browser best-efforts.

[marcoscaceres]

We've been successful encouraging OS API teams to make changes in the past (e.g., with the aforementioned dismissal callback on Windows). I think it would be worthwhile letting the Windows folks there is an issue.

@saschanaz, have you reached out to them?

[marcoscaceres]

@saschanaz, I see you followed up with the windows folks in the Chrome bug. Thanks for doing that.

[saschanaz]

The spec could gain a disclaimer paragraph, for platforms where it is not possible to distinguish cases 11.3, 11.5 and 11.6.

Only when we get a way to feature detect, I guess. I think any undetectable behavior differences are a mess 🤔

Edit: Random idea, but could we return undefined instead of Promise<undefined> when user action can't be tracked? Theoretically it's not a compatible change, but if websites are not affected by Edge behavior I think it means they are not really using the return value. Feature detecting via return type also should make fingerprinting harder in this case.

[mhochk]

Small clarification on the claim that the Edge implementation immediately resolves - it does wait till the data has been successfully handed off to the OS and reports back based on that. It's still not a spec match, but is worth distinguishing from "immediate" in that it is async, does sometimes fail or get cancelled, and is providing slightly more information to the calling site than if it were to not return a Promise at all.

Regarding a way to feature detect this I agree that detecting via return type may be the best way, though think it would be more appropriate as a return value passed to the Promise. I'm anticipating possible implementations based on the latest available Windows APIs that would be able to usually report success or failure, but sometimes won't know for certain what happened and I would expect those scenarios to report this same indeterminate result.

[marcoscaceres]

I think it's reasonable to assume that a best effort was made to hand a share off to the OS, and that hopefully the OS was able to give back the correct signals to the browser to indicate success/failure/abort... and where the OS can't give those assurances, resolve the promise. However, I think that should be implementation specific, because it may be that the Windows API ends up evolving over the next few years (i.e., we shouldn't work around current OS limitations in the spec - but we could note the reality of the situation in a note within the spec).

[saschanaz]

we shouldn't work around current OS limitations in the spec

I think we should do, as we can't really expect every OS provides same equivalent feature. Today it's Windows, but tomorrow it can be Ubuntu, KaiOS, or whatever new OS.

And especially when the old Windows builds won't die soon enough.

Edit: Did some chat, leaning to just allowing it for now and then seeing what really happens in real world. If it really turns out to be a problem we could add a return value, something like Response from fetch().

[marcoscaceres]

I concur that it's mostly wishful thinking on my part - and in practice, this might be ok as on most OSs share dialogs are non-blocking modal dialogs. So, I'd be ok with a "SHOULD" on this.

[saschanaz]

Note that Mozilla is now following what Chromium does: https://phabricator.services.mozilla.com/D121421

[marcoscaceres]

@saschanaz, sorry, it's been a while... do we need to update the spec or are we ok?

[saschanaz]

The spec should be revised to describe real browser behavior.

[marcoscaceres]

Happy to update, but could use some help.

The spec says (step 11.6):

Once the data has been successfully transmitted to the target, resolve [[sharePromise]] with undefined.

Isn't that what reflecting the browser behavior right now? I.e., we don't wait for confirmation or cancellation.

That seems to also align with the Gecko patch, in as far as that there is OS handoff of the data and that's as much as we can expect?

[saschanaz]

"the target" is the share target (this should be linked), not the OS, and it's the behavior on mobile devices. It should be loosened, something like:

Once the data has been successfully transmitted to the share target, or to the OS if the transmission to the share target cannot be detected, resolve [[sharePromise]] with undefined.

[marcoscaceres]

Thanks @saschanaz! the explanation helped a lot. I send #209 with some small clarifications. Let me know what you think!