Closed marcoscaceres closed 2 years ago
As we haven't managed to hear back from YouTube in a reasonable amount of time, I'd like to move on this and patch WebKit this week.
@saschanaz, what's you plan for Gecko?
TBH I'd like to keep it and instead inject the following as the workaround, if we want to keep the policy itself:
if (window.parent != window.top) {
navigator.share = undefined;
}
This at least activates the traditional fallback. (Sigh, we should have done this a year ago, idk why I didn't)
TBH I'd like to keep it and instead inject the following as the workaround, if we want to keep the policy itself:
Do you mean inject that specifically into YouTube frames?
My slight preference is also to keep it strict rather than allowing it to be open by default. I am following up with YouTube to see if we can properly fix the exception rather than having to inject a fallback like that.
Do you mean inject that specifically into YouTube frames?
Exactly.
My slight preference is also to keep it strict rather than allowing it to be open by default. I am following up with YouTube to see if we can properly fix the exception rather than having to inject a fallback like that.
👍
I have been trying to reproduce this issue specifically on YouTube, but I can't actually see a share button in the embedded player. It's possible that YouTube removed the share button for embedded players in the last 2 years.
Example: https://www.w3schools.com/html/tryit.asp?filename=tryhtml_youtubeiframe_autoplay I don't see a share button, nor is there one on the right-click menu, three-dot menu or settings menu. Tried in Chrome and Firefox. If there's no share button, then there's nothing to fix on the YT side, and our main concern about enabling this by default is removed.
@saschanaz have you been able to reproduce the broken share button on YouTube recently?
I have been trying to reproduce this issue specifically on YouTube, but I can't actually see a share button in the embedded player. It's possible that YouTube removed the share button for embedded players in the last 2 years.
No, it's done via third-party embedder like: http://youtubeembedcode.com/en/
And: https://youtubevideoembed.com
Which generate code like:
<iframe
src="https://www.youtube.com/embed/jNQXAC9IVRw?loop=1&modestbranding=1"
width="560" height="315"
frameborder="0"
allowfullscreen="">....</iframe>
The above shows the share button:
Note that the above src
is YouTube - so maybe it's a setting in YouTube itself saying "this video is sharable" or something.
Here is a more significant example (view source): https://diablo4.blizzard.com/en-us/
<iframe
class="absolute inset-0 w-full h-full"
width="560" height="315"
src="https://www.youtube.com/embed/LvrLZ4yETHI?autoplay=0&modestbranding=1"
frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen>…</iframe>
I should be more clear here that the various sites themselves would need to update their iframe
with allow="web-share"
to work.
Further, YouTube needs to update their own generated embed code. For example, it currently generates this (which is missing "web-share"):
For which, given a random video, does include the share button. https://jsbin.com/naxarebuwo/edit?html,output
Very strange. I was playing around with the various differences in the iframe embed code between the Muppets example on w3schools and the Diablo IV example you posted above. It turns out literally the thing that makes the difference is the video: Muppets does not have a share button, Diablo does.
I don't know why that is, but thanks, I have a minimal repro now so I can take it to the YouTube team.
Just Fyi, I've updated WebKit to use "*" in the interim to mitigate the current web compat issues.
@mgiuca, please let us know how you go with YouTube and happy to coordinate on a switch to self
.
Just touching base again as it's been over a month... how should we proceed? Give it more time or...?
Ok, this is the last outstanding issue in the spec. We've tried multiple times/ways of getting in touch with the YouTube folks for a while now but we've sadly not succeeded.
So, in the interest of moving forward, any objections with going down the "*" route? If I don't hear any objections, I'll merge this next week (on the 15th of July).
If there are objections, I'd like to hear about a tangible course of action.
Still not a big fan of this as there's not been too many reports of this from users. (No reports for Gecko AFAICT, except mine https://bugzilla.mozilla.org/buglist.cgi?quicksearch=youtube%20share&list_id=16140758)
One point is that it's weird to expose navigator.share
at all in a context that the browser knows it will always fail. Mozilla is seeing similar issue for IndexedDB (which currently always fails on private browsing mode on Gecko and the feature detection is not straightforward).
Might be worth to fix that as a general solution?
Still not a big fan of this as there's not been too many reports of this from users.
We've had the opposite experience on the Safari side.
One point is that it's weird to expose navigator.share at all in a context that the browser knows it will always fail. ... Might be worth to fix that as a general solution?
Might be tricky, but yeah... something like telling Permissions Policy to not expose the API at all (same way as secure-context works, but somehow configurable).
Gave this more thought... to allow us to proceed to CR, with my WG Chair hat on, we can mark this feature "at risk". That allows us to publish, and then we can try to sort out the Permissions Policy situation by the end of the year.
If we don't sort it out, we can remove it from the spec and then add it back at such time as we actually get interoperability.
Alright, I've updated the example and marked the feature at risk.
Closes #233
Preview | Diff