@ddbeck Further to this, the webshare spec states that navigator.share() should support sharing a base set of data types that might be shared, which includes: title, text, url, an array files

I just found this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1635700 which indicates that FF does not support file sharing.

Should we note this by marking the support in firefox as partial OR by adding a subfeature for files, url, whatever. Thoughts?

@saschanaz Do you know when/if this feature is expected for Firefox?

but without the partial implementation warning due, I think, to MacOS issues

Sorry, I didn't quite follow this. You didn't mark the Mac partial implementation because you didn't test it? Or had reason to believe that this is a Chrome-specific limitation? The rest of this seems fine to me, I just want to figure out when/where we ought to be copying notes.

but without the partial implementation warning due, I think, to MacOS issues

Coming back to this after a couple of weeks - yes, that note is gibberish sorry.

What I am saying is that Chrome marks canShare() support as partial - should I copy this "partial" to the other chromiums?

The only reason I am questioning this is because I don't know the reason this was marked as partial support in the first place. If this could be because it is not supported on macOS then I could omit this caveat on android platforms.

I guess I should add "partial" and the note for Opera though, as that runs on Mac.

Does the question make sense now?

Does the question make sense now?

Yes, this makes sense now. Reading the linked bug, it appears to be Mac specific, so I'd copy it to Edge and Opera. 👍

Thanks @ddbeck ,
I've added the note and partial_implementation to opera and Edge. Should be good now.

I just found this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1635700 which indicates that FF does not support file sharing.

Should we note this by marking the support in firefox as partial OR by adding a subfeature for files, url, whatever. Thoughts?

@saschanaz Do you know when/if this feature is expected for Firefox?

It's not expected anytime soon, and files support is added later to the spec separately, so 👍 to add a separate files data.

And also probably a good chance to use preview since it's enabled only on Nightly/early beta.

@ddbeck @saschanaz OK, I added a files subfeature with versions based on

• Safari/Safari iOS in v15 - https://blog.bitsrc.io/sharing-files-from-ios-15-safari-to-apps-using-web-share-c0e98f6a4971 [Note, that files may have been in Safari v14 behind a flag, but I couldn't find the information and not sure it is necessary?]
• Chrome https://www.chromestatus.com/feature/4777349178458112 - v76 android, 89 Chromium. Rolled it out everwhere.

Question. Could/should we add subfeatures for text as well? The reason I ask is that Firefox for android does not support text sharing (at the moment captured with a note).

And also probably a good chance to use preview since it's enabled only on Nightly/early beta.

@ddbeck How do you do both a preference and a preview version? This is what it looks like now

            "firefox": {
              "version_added": "71",
              "flags": [
                {
                  "type": "preference",
                  "name": "#dom.webshare.enabled",
                  "value_to_set": "enabled"
                }
              ]
            },

This was added in nightly in FF92 - see https://bugzilla.mozilla.org/show_bug.cgi?id=1641280 . I think it was only added for Windows though - dunno if that matters (i.e. it doesn't if preview is assumed to be Windows for Firefox).
I tried a few variants like this, but it can't cope with "preview". Ideas?

            "firefox": [
              {
                "version_added": "preview"
              },
              {
                "version_added": "71",
                "version_removed": "91",
                "flags": [
                  {
                    "type": "preference",
                    "name": "#dom.webshare.enabled",
                    "value_to_set": "enabled"
                  }
                ]
              }
            ],

Thanks, all helpful. I'll make the required changes tomorrow.

@ddbeck

1. By "can't cope with preview", I mean I tried the following and got an error related to using the term "preview". I tried a number of other variants, and they gave me an error warning too. So my question was "what does it have to look like". I will try this again tomorrow and post the actual error for this to provide more data.

            "firefox": [
              {
                "version_added": "preview"
              },
              {
                "version_added": "71",
                "version_removed": "91",
                "flags": [
                  {
                    "type": "preference",
                    "name": "#dom.webshare.enabled",
                    "value_to_set": "enabled"
                  }
                ]
              }
            ],

2. With respect to the story ...

The story that I "know" is that prior to FF92 it is available behind pref ( 71-91), in FF92 it is available in Nightly by default and behind the pref for release.

The restriction to Windows confuses me. My original understanding was that the preference change in Nightly was only for Windows, but that doesn't make much sense.

@saschanaz is this a partial implementation? - ie this only works on Windows, or is it that we only enabled it for Windows, or is it that it behaves differently on Windows? Can you confirm?

@saschanaz is this a partial implementation? - ie this only works on Windows, or is it that we only enabled it for Windows, or is it that it behaves differently on Windows? Can you confirm?

It's enabled on Windows and Android, and should generally work same way on both, except a nit: Windows does not support tracking share action properly, so it resolves after opening the share popup, not after completing the share action. (Same for Chrome)

except a nit: Windows does not support tracking share action properly, so it resolves after opening the share popup, not after completing the share action. (Same for Chrome)

@saschanaz Ah, that wasn't clear to me, and makes this wrong: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share

My understanding was that is that this should be re-written as:

On Windows the method resolves a Promise with undefined as soon as the share popup has launched. On other platforms it resolves the promise with undefined once data is successfully passed to the share target.

Is that correct? Note the assertions:

• in both cases it resolves with undefined.
• resolved when "data is passed to the share target" (i.e. bluetooth) NOT when actually sent/recieved. So completion on Android means "prompt has closed and data sent to the OS API that does the sending"

I will correct the docs in line with your comment, but NOT record this nit as a compatibility issue in BCD.

@ddbeck I have added data_parameter_files and data_parameter_text to share and canShare. These mirror each other. The Chrome mac bug refers to files and it isn't clear if it also applies to text - but it might so I have left that in.

With respect to adding preview, I still don't get how to do that. The story I am trying to tell is that it was added in version 71 behind a preference. From version 92 it is released (no pref required) in Nightly.

I tried the following, but get Error: Invalid argument not valid semver ('preview' received)

            "firefox": [
              {
                "version_added": "preview"
              },
              {
                "version_added": "71",
                "flags": [
                  {
                    "type": "preference",
                    "name": "#dom.webshare.enabled",
                    "value_to_set": "enabled"
                  }
                ]
              }
            ],

resolved when "data is passed to the share target" (i.e. bluetooth) NOT when actually sent/recieved.

I don't think this can be a strong assertion as each OS may behave different. But correct at least on Android.

@ddbeck When you get a chance, this needs re-review. As discussed, this is not an immediate priority, just keeping it visible.

@ddbeck Thanks for the review. I've "accepted all".