You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's currently no spec text around whether a given share target should show up for a given ShareData. This is relevant with file sharing, as we should be able to answer questions like:
If I share some data without a file, should share targets that accept files show up?
If I share some data with a file, should share targets that don't accept files show up?
And various permutations of that.
There's a small statement about this in "Registration of web share targets":
If a file being shared is not accepted by any of a share target's files entries, the user MUST NOT be presented with that web share target as an option.
But this could be expanded.
The text was updated successfully, but these errors were encountered:
We're getting some reports about "unexpected" behaviour of Web Share targets showing up / not showing up in Chrome. e.g. https://crbug.com/1163781
However, I think the problem is that the manifest format simply isn't expressive enough (or we haven't thought hard enough about how to interpret it) to convey the intention of each app.
For example, a photo sharing app probably should not show up if you are sharing text-only, whereas an email client probably should show up if you are sharing text-only, even though it also is happy to accept files.
If you're sharing a file without any text data, an app that only accepts text data should probably not show up. But if you're sharing a file with text data, I don't even know whether an app that only accepts text data would want to show up or not.
There's currently no spec text around whether a given share target should show up for a given ShareData. This is relevant with file sharing, as we should be able to answer questions like:
And various permutations of that.
There's a small statement about this in "Registration of web share targets":
But this could be expanded.
The text was updated successfully, but these errors were encountered: