rfc: clipboard rearchitecture

[jkleinsc]

This RFC outlines a rearchitecturing of the clipboard module in Electron to improve alignment with the Clipboard API as specified by the W3C.

📄 Read rendered document

coauthored with @codebytere.

[dhimmel]

It's not clear to me whether electron can access arbitrary clipboard formats outside of a subset of whitelisted platform specific types. This uncertainty exists both for the current electron version (v37), as reported in electron/electron#39853 (comment), and in the proposed changes in this RFC.

AFAIU the W3C Async Clipboard API supports access to only a subset of possible formats as specified in well-known mime types and the clipboard API working draft which notes support of those with a web prefix (and this RFC adapts for an electron prefix).

Is access to arbitrary clipboard formats:

• intended to work in the current electron clipboard API
• intended to work in the proposed rearchitected clipboard API

This is a critical feature for my use case and I was encouraged to see this RFC in case there is any relation.

[dhimmel]

With Electron 38 on Windows, clipboard.read and clipboard.readBuffer can access arbitrary clipboard formats. So I think we can conclude that prior to this re-architecture, the Electron intends to be able to read/write any clipboard format. And that this rearchitecture should preserve and refine this ability. By refine, I mean enhancements like making clipboard.availableFormats actually detect all available formats.

[jkleinsc]

@dhimmel the intention would be that we wouldn’t lose any current functionality, so if a format is readable now it should be so after this change goes through. The problem right now is that you have to know these weird platform specific formats exist and then use stuff like readBuffer to get the data.

I think we might end up missing some formats on the initial implementation but I’d expect that we’d add them through follow up PRs. If there are particular formats you are interested in, feel free to mention them here.

[dhimmel]

Sounds good with the clarifications in e642a54. Thanks for you work.

The current functionality to read raw formats will be maintained with the electron application/osclipboard;format="OS CLIPBOARD NAME HERE" syntax. Note the space in the format name. Supporting spaces is important for our use case.

clipboard.read will be able to list all available formats. Hopefully this includes the electron application/osclipboard formats.

If there are particular formats you are interested in, feel free to mention them here

The RTF functionality. clipboard.readRTF function is going away but using the MIME type application/rtf is an adequate substitute and will work across platforms.

[erickzhao]

RFC LGTM

[reitowo]

RFC LGTM

[itsananderson]

RFC LGTM

[ToxicMushroom]

This function has an optional parameter to request reading only particular formats https://w3c.github.io/clipboard-apis/#dom-clipboard-read. Is it left out on purpose here ?

[jkleinsc]

@ToxicMushroom that parameter is specced as
formats
An optional object with the following properties:
unsanitized
An Array of strings containing MIME types of data formats that should not be sanitized when reading from the clipboard.

So, it really is just to specify which (if any) formats should not be sanitized, not to request reading only particular formats and in the spec, the only format this applies to is text/html: https://w3c.github.io/clipboard-apis/#unsanitized-data-types-x

The clipboard module in Electron has always returned the unsanitized clipboard values, so passing this parameter isn't really useful in Electron.

If you wanted to read only particular formats, you could do something like:

const clipboardFormatsToRead = ['image/png', 'text/html'];
const clipboardContents = await clipboard.read();
for (const item of clipboardContents) {
  for (const clipboardFormat of clipboardFormatsToRead) {
    if (item.types.includes(clipboardFormat)) {
      const blob = await item.getType(clipboardFormat);
      //Do something with the blob
    }
  }
}

[ToxicMushroom]

My bad! Thanks for clearing that up.

[erickzhao]

After some discussion in last week's API WG meeting, we decided to incorporate @nmggithub's clipboard privacy PR into the final design:

electron/electron#49567

[nmggithub]

After some discussion in last week's API WG meeting, we decided to incorporate @nmggithub's clipboard privacy PR into the final design:

electron/electron#49567

For additional context from the meeting, I mentioned (and still believe) the privacy option, however we end up expressing it, would be best used as a custom field on a ClipboardItem.