Sharing files #78

ewilligers · 2018-09-26T01:30:24Z

Add a files member to Web Share dictionary.

Add canShare() so authors can determine if an implementation supports sharing a given ShareData dictionary. In particular, this allows authors to determine if an implementation supports sharing files.

Preview | Diff

mgiuca · 2018-09-27T03:59:50Z

index.html

@@ -224,6 +243,7 @@ <h3>
            USVString title;
            USVString text;
            USVString url;
+            FileList files;


For some reason, this hasn't been linked properly in the preview. Maybe you need to reference !FILE-API somehow as a dependency for this text box.

Also, I wonder if FileList should be considered deprecated, due to the comment here:

Note: The FileList interface should be considered "at risk" since the general trend on the Web Platform is to replace such interfaces with the Array platform object in ECMAScript [ECMA-262].

I wonder if FileList should be considered deprecated

FileList is used widely. It should be safe to use. I haven't seen sequence<File> used anywhere, other than as the definition of FileList in early versions of the File API.

We won't use item() calls in any examples, due to the "at risk" comment.

The link in the IDL is now fixed.

mgiuca · 2018-09-27T04:01:35Z

index.html

@@ -95,6 +95,7 @@ <h3>
        </p>
        <pre class="idl">
          partial interface Navigator {
+            [SecureContext] boolean canShare(optional ShareData data);


We've talked on whatwg/webidl#107 about a more generic solution to feature detection of dictionary members, than every API making its own canX method. Perhaps we should check up on the status of that.

Discussion is ongoing...

mgiuca · 2018-09-27T04:03:23Z

index.html

+            <var>data</var>, run the following steps:
+          </p>
+          <ol data-link-for="ShareData">
+            <li>If none of <var>data</var>'s members <a>title</a>, <a>text</a>,


This doesn't really capture what happens if files is not supported. I know the spec assumes that it is (since an implementation compliant with the latest spec would support file sharing), but what if it isn't?

If files isn't supported, does it return true or false if I include both files and some other supported field?

Additional unsupported dictionary fields are ignored. (We could mention that explicitly.) If an implementation chose to support canShare but not file sharing, then (a) that implementation would not be consistent with any version of the spec, (b) that implementation should return false if the dictionary only contained files. If would return true if the dictionary also contained some other supported field.

Adding text to say the method must return false if the dictionary contains files and file sharing is not supported would be possible for the special case of files, but similar text would probably not be possible for any future fields that might be added in future versions.

If an implementation chose to support canShare but not file sharing, then (a) that implementation would not be consistent with any version of the spec

I guess this is important for how developers are expected to use it.

Are we leaving open a possibility of an intermediate browser that supports canShare but not files? It's possible that a future browser will never want to support file sharing (because the OS doesn't have a concept of files, or whatever), but will want to support some other new feature that requires canShare. So I think we should allow this, possibly even explicitly saying that files is a MAY (not a MUST), and linking up canShare so it MUST return true if and only if files is accepted.

If we are allowing this possibility of canShare without files, then we need to enumerate this case, and that means developers are expected to check for both canShare and files, like this:

if (navigator.share && navigator.canShare && navigator.canShare({files})) { await showShareButton(); navigator.share({files}); }

If we aren't, then it means the very existence of canShare implies that files is supported, so then developers have a legitimate expectation of this code always being correct:

if (navigator.share && navigator.canShare) { await showShareButton(); navigator.share({files}); }

The latter option seems silly to me, so I think we should require developers to actually call canShare if they want to check if file sharing is allowed, which means we need to allow canShare to exist, but return false if given files.

mgiuca · 2018-10-01T05:43:55Z

index.html

+            <var>data</var>, run the following steps:
+          </p>
+          <ol data-link-for="ShareData">
+            <li>If none of <var>data</var>'s members <a>title</a>, <a>text</a>,


If an implementation chose to support canShare but not file sharing, then (a) that implementation would not be consistent with any version of the spec

I guess this is important for how developers are expected to use it.

Are we leaving open a possibility of an intermediate browser that supports canShare but not files? It's possible that a future browser will never want to support file sharing (because the OS doesn't have a concept of files, or whatever), but will want to support some other new feature that requires canShare. So I think we should allow this, possibly even explicitly saying that files is a MAY (not a MUST), and linking up canShare so it MUST return true if and only if files is accepted.

If we are allowing this possibility of canShare without files, then we need to enumerate this case, and that means developers are expected to check for both canShare and files, like this:

if (navigator.share && navigator.canShare && navigator.canShare({files})) { await showShareButton(); navigator.share({files}); }

If we aren't, then it means the very existence of canShare implies that files is supported, so then developers have a legitimate expectation of this code always being correct:

if (navigator.share && navigator.canShare) { await showShareButton(); navigator.share({files}); }

The latter option seems silly to me, so I think we should require developers to actually call canShare if they want to check if file sharing is allowed, which means we need to allow canShare to exist, but return false if given files.

mgiuca · 2018-10-01T05:46:41Z

index.html

+          </ol>
+          <div class="note" data-link-for="ShareData">
+            <p>
+              <code>canShare()</code> MUST return <code>false</code> whenever


This is normative, and therefore shouldn't be in a note. (I must've missed this text last time I looked.)

This is actually not true, as stated. If url is invalid, share should reject with TypeError, but canShare should return true because it doesn't check URL. I think canShare should return false if url is invalid, and thus this statement here better matches what I want than the definition above.

I think I'd be happier with this being the definition of canShare, rather than a corollary (so we don't have to duplicate or abstract out the checking logic). Do you think we can get away with simply deleting the steps, and writing "canShare() MUST return false whenever ..... It MUST return true otherwise." ?

mgiuca · 2018-10-01T05:46:58Z

index.html

@@ -95,6 +95,7 @@ <h3>
        </p>
        <pre class="idl">
          partial interface Navigator {
+            [SecureContext] boolean canShare(optional ShareData data);


Discussion is ongoing...

mgiuca

Looks good, but did you want to do the Level 2 thing we talked about, where you copy the spec into a new HTML page, and add this stuff there? Thus we avoid having canShare be part of the basic spec.

mgiuca · 2018-10-09T04:47:31Z

index.html

+            <dfn>canShare()</dfn> method
+          </h4>
+          <p>
+            <code>canShare(</code><var>data</var><code>)</code> returns


MUST return true unless .... in which case it MUST return false.

mgiuca · 2018-10-09T04:50:14Z

index.html

            <a>TypeError</a>, and abort these steps.
            </li>
+            <li>If the implementation does not support file sharing and none of


This does not seem sustainable; imagine adding another optional member, the permutations.

I would rather just delete this, and add a parenthetical above, like this:

"If none of data's members title, text, or url are present, reject p with url or (if the implementation supports file sharing) files are present"

Add a files member to Web Share dictionary. Add canShare() so authors can determine if an implementation supports sharing a given ShareData dictionary. In particular, this allows authors to determine if an implementation supports sharing files.

ewilligers · 2018-10-10T00:25:47Z

Rebased to Level 2, comments addressed.

mgiuca

LGTM. Thanks for rebasing onto Level 2.

I think this is a good structure for discussing potentially wild changes while keeping the "classic" Web Share spec stable.

mgiuca reviewed Sep 27, 2018

View reviewed changes

mgiuca mentioned this pull request Sep 27, 2018

Need pattern for feature detecting dictionary members whatwg/webidl#107

Open

ewilligers force-pushed the sharing-files branch from 4ffcbdd to 40bf9f6 Compare September 28, 2018 03:02

mgiuca reviewed Oct 1, 2018

View reviewed changes

mgiuca reviewed Oct 9, 2018

View reviewed changes

Sharing files

18e0eff

Add a files member to Web Share dictionary. Add canShare() so authors can determine if an implementation supports sharing a given ShareData dictionary. In particular, this allows authors to determine if an implementation supports sharing files.

ewilligers force-pushed the sharing-files branch from 07223d5 to 18e0eff Compare October 10, 2018 00:25

mgiuca approved these changes Oct 10, 2018

View reviewed changes

ewilligers merged commit fb374da into w3c:master Oct 10, 2018

ewilligers deleted the sharing-files branch October 10, 2018 09:40

ewilligers mentioned this pull request Aug 27, 2020

canShare() is not future compatible #108

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sharing files #78

Sharing files #78

ewilligers commented Sep 26, 2018 •

edited by pr-preview bot

Loading

mgiuca Sep 27, 2018

mgiuca Sep 27, 2018

ewilligers Sep 28, 2018

ewilligers Sep 28, 2018

mgiuca Sep 27, 2018

mgiuca Oct 1, 2018

mgiuca Sep 27, 2018

ewilligers Sep 28, 2018

ewilligers Sep 28, 2018

mgiuca Oct 1, 2018

mgiuca Oct 1, 2018

mgiuca Oct 1, 2018

mgiuca Oct 1, 2018

mgiuca left a comment

mgiuca Oct 9, 2018

mgiuca Oct 9, 2018

ewilligers commented Oct 10, 2018

mgiuca left a comment

Sharing files #78

Sharing files #78

Conversation

ewilligers commented Sep 26, 2018 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mgiuca left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ewilligers commented Oct 10, 2018

mgiuca left a comment

Choose a reason for hiding this comment

ewilligers commented Sep 26, 2018 •

edited by pr-preview bot

Loading