Closed Bug 1560373 Opened 5 years ago Closed 4 years ago

Clipboard API: 'clipboard-write' is not a valid value for enumeration PermissionName

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: leplatrem, Unassigned)

References

(Blocks 1 open bug)

Details

I followed MDN instructions to copy text to the clipboard:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Interact_with_the_clipboard#Using_the_Clipboard_API

Basically:

    const { state } = await navigator.permissions.query({
      name: "clipboard-write",
    });
    if (state == "granted" || state == "prompt") {
      await navigator.clipboard.writeText(s || "");
    }

But I get this error in Firefox only: TypeError: "'name' member of PermissionDescriptor 'clipboard-write' is not a valid value for enumeration PermissionName."

I found this https://github.com/w3c/clipboard-apis/commit/aa1f8ac45ffc3ff9035fa64519c5c822ab28469c but I don't get more success using the former permission name "write"

Type: defect → enhancement
Priority: -- → P3

Just to try to help:

Websites are under the gun for enhancing their users' security, but if we can't control something as simple as clipboard use permissions, it creates a legal Catch-22 for website owners who interact with users in the EU. Luckily, FF isn't the only browser out there.

Chrome and Chromium both require HTTPS in order to "unlock" this feature, to both reduce the influence of JS injection and end-user interference. Handing the permission with cookies seems like a very, very bad idea, since the clipboard is integrated beyond the app and into the OS.

This might be worth more than a P3, since it directly impacts the ability to work with things like online document editing and restricting or permitting password input field value access (handy for those who use password management applications like KeePass). And the fact is, at least handling the variables that other browsers accept (even if that "handling" is to ignore the name attribute that others use) would prevent an error in my own app that essentially blocks access to a web page that sits and awaits that permission.

Your error stops my app cold, so your browser is excluded until that particular item is fixed. The chances of my being popular enough to influence this decision being small, I would rather appeal to your logic and try to see beyond my own interests and into the interests of those who favor browsers like FIrefox. Myself included.

On the Permissions query page it says that clipboard-write is a valid value: https://developer.mozilla.org/en-US/docs/Web/API/Permissions/query

Those docs should be updated, because it lists many "valid" values which aren't in the enum listed above (https://dxr.mozilla.org/mozilla-central/source/dom/webidl/Permissions.webidl#10)

(In reply to mofojed from comment #4)

On the Permissions query page it says that clipboard-write is a valid value: https://developer.mozilla.org/en-US/docs/Web/API/Permissions/query

Those docs should be updated, because it lists many "valid" values which aren't in the enum listed above (https://dxr.mozilla.org/mozilla-central/source/dom/webidl/Permissions.webidl#10)

I've edited https://wiki.developer.mozilla.org/en-US/docs/Web/API/Permissions/query#Parameters to make the page more accurate, as a short-term fix. Ideally in the longer term we should have a detailed list of exaxctly which. browsers support what permission names.

I guess supporting clipboard-write and clipboard-read permissions would enable us to use the asynchronous Clipboard API.

Since as per MDN docs Firefox only supports reading the clipboard in browser extensions, using the "clipboardRead" extension permission unlike Chrome.

Seriously, I've had to rethink how to go about copying text to a clipboard because of a websocket call inbetween clicking a button because of this permission. Please fix this.

Blocks: 1619251

Firefox (and Safari as well, per standards discussions) are pushing back against clipboard-write as there is no good way to offer this functionality with informed user consent. It's being removed from the specification.

It might still be reasonable to expose this to extensions, but that should be tracked separately.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX

Are there plans for a more secure replacement for access to the clipboard then?

Accessing the clipboard is pretty important for many web apps. Using the browser's clipboard hotkeys is fine, but doesn't address the following problems:

  • Many users are completely unfamiliar with hotkeys, and training users to use Ctrl+C and Ctrl+V is difficult and disruptive to the user.
  • On mobile (touch) devices, there isn't a good way (or any way?) to invoke clipboard events on something other than a text area (for example, a <canvas>), which makes the ability for the web developer to make custom clipboard UI critical.

I understand that there are significant security challenges here, but there really needs to be some solution for this. I would rather prompt the user for permission on every attempt to use the async clipboard API, then not have access to it at all.

Flags: needinfo?(annevk)

Thank you for your post!

I would rather prompt the user for permission on every attempt to use the async clipboard API, then not have access to it at all.
I think this is not a good idea and I explain why: There is a major difference between just overwriting the clipboard (usually with text only) and getting arbitrary content from the clipboard. While it is very common and useful to overwrite the users clipboard, it is not so common to fetch any content from it. So, users should only be asked for permissions in case the website tries to fetch content from the clipboard, but not, if it is just overwritten. If we would require users also to explicitly allow the permission to overwrite the clipboard, they will more tend to confirm the dialog without thinking because many websites will then ask for such a permission, while not many will ask for fetching clipboard content.

However, we could require the permissions dialog for overwriting the clipboard also in case the website tries to insert any non-text content.

(Formatting fixed, sorry for double-post)

Thank you for your post!

I would rather prompt the user for permission on every attempt to use the async clipboard API, then not have access to it at all.

I think this is not a good idea and I explain why: There is a major difference between just overwriting the clipboard (usually with text only) and getting arbitrary content from the clipboard. While it is very common and useful to overwrite the users clipboard, it is not so common to fetch any content from it. So, users should only be asked for permissions in case the website tries to fetch content from the clipboard, but not, if it is just overwritten. If we would require users also to explicitly allow the permission to overwrite the clipboard, they will more tend to confirm the dialog without thinking because many websites will then ask for such a permission, while not many will ask for fetching clipboard content.

However, we could require the permissions dialog for overwriting the clipboard also in case the website tries to insert any non-text content.

So to be clear, you can already write to the clipboard with a user gesture, custom selection, and document.execCommand("copy"). Supporting writeText() and write() in a similar fashion with a user gesture requirement is reasonable and in scope for bug 1619251. But that's not the clipboard-write permission. For reading we would also want to require a user gesture and I think additionally some UI that makes it clear the user is pasting something. Safari's approach there is quite reasonable.

Flags: needinfo?(annevk)
You need to log in before you can comment on or make changes to this bug.