-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editorial: mark permissions policy at risk #234
Conversation
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) |
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. |
Exactly.
👍 |
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 @saschanaz have you been able to reproduce the broken share button on YouTube recently? |
No, it's done via third-party embedder like: And: 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 |
Here is a more significant example (view source): <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 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. |
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 |
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 Might be worth to fix that as a general solution? |
We've had the opposite experience on the Safari side.
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