Reproducible on windows only it seems

Steps to Reproduce:

Navigate to https://sway.office.com/howtosway
Scroll down to "Adding videos and animated images" section.
Click to play the video.
Click "Share" button and observe the behavior.

Expected Behavior:
A popup with apps to share the video is displayed.

Actual Behavior:
Nothing happens, the video can be shared.

Raul Bucata ran a mozregression and found Bug 1641280

Last good revision: c9fb00a913c9c66ccfced161ba622d6f7aa64e1f
First bad revision: aa2915f66825a78ca4ca73d2fea217d88662654a
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c9fb00a913c9c66ccfced161ba622d6f7aa64e1f&tochange=aa2915f66825a78ca4ca73d2fea217d88662654a

Set release status flags based on info from the regressing bug 1641280

:saschanaz, do you have an idea why this is happening?

Hmm, this sounds like a permission policy issue. The Web Share spec says the policy is self by default and thus is disabled by default in cross origin iframes. This is implemented by bug 1653199 but I don't think it's really web compatible, since Chrome does not implement the policy at all and the existing iframes have no allow="web-share".

Hey Marcos, should the spec say * by default? Also, you said in https://github.com/w3c/web-share/issues/169#issuecomment-934174054 that the policy is implemented in WebKit too, but no one passes the tests. Do you know what happened there? (The Firefox failures are just because the flag dom.security.featurePolicy.webidl.enabled is not given.)

Ah!

we had Bug 1701841, which was closed because this is a bug in Chromium!
I should have thought about it.
https://bugs.chromium.org/p/chromium/issues/detail?id=1196138

I will add it to the list of things that Chromium should fix in 2022 for fixing webcompat issues.

Thanks! I also hope YouTube add a proper fallback when share fails.

If we can convince them maybe no need to change the spec.

(In reply to Kagami :saschanaz from comment #3)

Hey Marcos, should the spec say * by default? Also, you said in https://github.com/w3c/web-share/issues/169#issuecomment-934174054 that the policy is implemented in WebKit too, but no one passes the tests. Do you know what happened there? (The Firefox failures are just because the flag dom.security.featurePolicy.webidl.enabled is not given.)

It's implemented in WebKit (engine), but hasn't been uplifted to Safari TP yet.

Just confirming... this was the patch on the WebKit side:
https://bugs.webkit.org/show_bug.cgi?id=214448

And it's in the tree:
https://github.com/WebKit/WebKit/blob/d52ee1d3dda3aaecaf92ecb6fbb41f54ac51b3f7/Source/WebCore/html/FeaturePolicy.cpp#L60-L61

(Was checking that maybe it got backed out since it landed... but still there... I'll check the tests too).

As far as I can tell, this issue has nothing to do with PiP, but instead is a result of Chrome and Firefox/Safari disagreeing on Permission Policies around Web Share in iFrames.

A YouTube-specific intervention will be shipping in 104 as per bug 1772949, but since that doesn't resolve the underlying issue, I'll re-purpose this bug to keep track of that.

The severity field for this bug is relatively low, S3. However, the bug has 6 See Also bugs.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #9)

The severity field for this bug is relatively low, S3. However, the bug has 6 See Also bugs.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Kagami knows the best for the whole Web Share story, so I'd like to defer to them here, while I also wonder if "task" is a better type for this given that the spec solution is still under discussion and exploration. Thank you, Kagami. :)

The corresponding site intervention is live in Nightly. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1772949#c5.

To summarize the situation:

1. The spec authors think web-share is powerful enough to have a permission
2. But YouTube does not give the right permission to the iframe
3. People have been contacting YouTube but they have been dead silent.

So the site intervention. There are a few more known breakages (e.g. https://github.com/jsbin/jsbin/issues/3485) but none is impactful as YouTube is, naturally.

tl;dr: I think S3 is fine.

YouTube fixed the issue on their side, and now Chrome behaves same as Firefox does. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1835415#c1.