Chrome-based browser is blocking clipboard about twitch-hdt-frontend HOT 9 OPEN

Fallback has been added in ceef05a, waiting for Twitch approval.

from twitch-hdt-frontend.

This is due to Chrome's new(?) cross-domain iframe permissions, which it doesn't grant to our extension. I've tried using the permissions API locally to test whether we can request permission, but I haven't had much success. We'll probably have to add a text-based "copy text" fallback like on mobile. In the mean time, you'll need to use another browser instead.

from twitch-hdt-frontend.

What happened here is that Chrome implemented a new permission system for clipboard, in the name of web security (great!). This means that browser will be able to better negotiate clipboard-permissions with the website, like disallowing non-interactive clipboard access, or requiring the user to accept a prompt for the website to access their clipboard. We should totally do that.

Additionally Chrome has now put cross-origin clipboard access behind a feature policy, in order to protect users of the top-level site. This affects us because our extension is embedded in an iframe in Twitch through a cross-origin domain. Unfortunately they forgot to actually fully implement this feature policy, meaning that we (or even Twitch for that matter) cannot grant the feature policy to the extension's iframe (bad!). This is being worked on.

So for our extension, I think we want the following approach:

1. When a user clicks on the copy button, we should check the current permission status (via navigator.permissions.query) using the query {name: 'clipboard-write', allowWithoutSanitization: false, allowWithoutGesture: false} (we do not need raw clipboard-write access, and we will always access it based on a user gesture).
2. If the result is denied, we drop to a readonly textarea and the user will have to manually right-click and copy. This is like it's handled on mobile today.
3. If the result is granted, we invoke the copy APIs as they've been invoked so far.
4. If the result is prompt, we need to actually request the permission somehow (tbd, needs more research). This could be as easy as just trying to access the clipboard APIs.
5. If the permission query is not understood and throws an exception (i.e. browser that do not understand this permission yet) we simply assume it's granted.

At this time we're just writing to the clipboard to allow the browser to prompt the user. If the clipboard call fails, we fall back to a textarea and allow the user to copy manually.

This should make the extension tolerant to the various browser-behaviours, and should silently revert back from the text-based fallback to the onclick behaviour once 1) Twitch adds clipboard to the extension iframe's feature policy (allow="...; clipboard" see below, needs allow="...; clipboard-write" instead) and 2) Chrome supports that new feature policy.

In order to get Twitch to add the clipboard feature policy to their iframe I'll ping them about this once it's actually live in Chrome, and then they can still decide if they want to do this or not. In any case the extension will be able to fall back using the logic outlined above.

from twitch-hdt-frontend.

The Chromium change is making progress. Looks like the feature policy has now been split up into clipboard-read and clipboard-write to match the permission, so once this is shipped we'll need to ask Twitch to add at least clipboard-write to the Extension iframe (via allow="...; clipboard-write"). Our extension only needs write access to copy something into the clipboard, read access is a little more dangerous (because you can potentionally steal whatever is in the user's clipboard).

from twitch-hdt-frontend.

1.0.1 with the fallback is live on Twitch. Keeping this issue open to track Chrome and Twitch implementing the feature policy.

from twitch-hdt-frontend.

Regarding the Chrome bug, a fix is now merged to Chrome M85+. Feature policies clipboard-read and clipboard-write may be used to control the Clipboard API in iframes. For more information, please see https://crbug.com/1074489.

from twitch-hdt-frontend.

As a funny twinkle to all of this, we've now discovered that the clipboard-write permission is not required when using the old document.execCommand('copy') API in Chrome. As Twitch has been slow to add clipboard-write to the extension's iframe sandbox attribute we could have the extension simply fall back to document.execCommand if a permission query returns denied to avoid prompting the user with the textbox to manually copy from.

This all feels a bit backwards, but would be a temporary measure for us until Twitch finally adds this attribute to their whitelist.
There's also a chance this breaks again when Chrome starts putting execCommand('copy') behind the same clipboard-write permission, but even a proposed secure context requirement has not been implemented since 2019. The execCommand('copy') API could also eventually be removed. Neither events seem very likely at this time, especially as I can't see any non-Chromium signals to implement the specific permission anytime soon.

from twitch-hdt-frontend.

Related: w3c/webappsec-permissions-policy#322

In the long-term we'll have to ask Twitch to enable this, but for now a workaround is probably the best. It seems like this changed behaviour was actually unintentional on Chrome/Blink's side for now and they're working on reverting it.

from twitch-hdt-frontend.

Great, thank you!

from twitch-hdt-frontend.