Conditionally exposing share() is not great

[marcoscaceres]

Spec says:

User agents that do not support sharing SHOULD NOT expose share on the Navigator interface.

This doesn't seem great. A share target can be removed/added, etc. making this super weird if the API vanishes from one page load to the next.

What we should have a is static method a on Navigator, or just normal method even, as navigator is just a singleton:

if(await navigator.canShare()){
   await navigator.share(stuff);
}

[mgiuca]

A share target can be removed/added, etc. making this super weird if the API vanishes from one page load to the next.

This is not allowed by the spec. This clause is supposed to be a static decision that is compiled into the user agent; navigator.share either exists, or it doesn't.

Some context:

• We originally did spec a canShare method (and I believe implemented it in Chrome).
  • Original spec text; though we would probably make it async.
• Remove canShare method? #5 "Remove canShare method?" -- ironically this bug begins with "As discussed with @marcoscaceres yesterday, the canShare method may be unnecessary." 🤣
• Removed navigator.canShare. #8 Removed this method from the spec. Note the long discussion on that thread.

A summary of the reasoning for removing it is:

• User agents should always have at least one share target (even if it's just "copy to clipboard"), so share should either always be available, or never, as a static property of the user agent. (Note: "Chrome for Android" and "Chrome for Windows" being considered two different user agents in this context; one can have it available, the other not.)
• Thus, if we provided canShare, it would likely be statically programmed to always return "false" or "true" depending on the user agent. Admittedly, a user agent could decide to have no built-in share targets, and thus program canShare to return (num_share_targets > 0), but we think this is unlikely.
• Developers would still need to feature-detect the existence of the API as well (since some browsers won't expose it, at least for the foreseeable future). And having two methods, you'll potentially have to feature-detect both share and canShare (we have already launched a user agent with share but not canShare). Thus, your feature detection code goes from this:

if (!navigator.share)
  return;

to this:

if (!navigator.share)
  return;

if (navigator.canShare) {
  // Assuming you use async; otherwise it's more complicated.
  if (!(await navigator.canShare()))
    return;
}

It doesn't seem worth making developers do 3 checks, if navigator.canShare will almost always exist and return true if share exists.

Do other implementors (Firefox?) feel the need to dynamically enable/disable sharing as share targets become available or unavailable?

[marcoscaceres]

Heh, I had a feeling we had discussed this. As you said, given that there is probably only going to always be one, then canShare() is indeed unnecessary. If we want to have a pref to allow users to disable the API, then indeed not having it show up at all is the right solution.