rfc: clipboard rearchitecture #19
Conversation
jkleinsc
force-pushed
the
clipboard-rearch
branch
from
ffecfac to
a924f35
Compare
erickzhao
added
the
pending-review
| * Custom MIME types e.g. `electron application/filepath` will be used to allow support of non-standard clipboard formats. This follows | ||
| the W3C proposal for supporting [Web Custom formats for Async Clipboard API](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#custom-formats). | ||
| The exception here is that instead of using the `web` prefix, we will use the `electron` prefix to prevent possible collisions with custom web formats. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
| * `clipboardType` string (optional) - Can be `selection` or `clipboard`; default is `clipboard`. `selection` is only available on Linux. | ||
| * This API will be modified to bring into spec compliance with the [Web API clipboard.read](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read) | ||
| * Returns a Promise that resolves with an array of [ClipboardItem](https://developer.mozilla.org/en-US/docs/Web/API/ClipboardItem) objects containing the | ||
| clipboard's contents. The promise is rejected if permission to access the clipboard is not granted. |
There was a problem hiding this comment.
Presumably this permission check wouldn't apply in the main process?
| * `clipboard.read([clipboardType])` | ||
| * `clipboardType` string (optional) - Can be `selection` or `clipboard`; default is `clipboard`. `selection` is only available on Linux. | ||
| * This API will be modified to bring into spec compliance with the [Web API clipboard.read](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read) | ||
| * Returns a Promise that resolves with an array of [ClipboardItem](https://developer.mozilla.org/en-US/docs/Web/API/ClipboardItem) objects containing the |
There was a problem hiding this comment.
From the ClipboardItem docs, it seems like a single ClipboardItem has a types array which lets it contain multiple clipboard types. Would we need to return an array of ClipboardItem, or would one ClipboardItem be sufficient?
| * This API will be modified to bring into spec compliance with the [Web API clipboard.read](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read) | ||
| * Returns a Promise that resolves with an array of [ClipboardItem](https://developer.mozilla.org/en-US/docs/Web/API/ClipboardItem) objects containing the | ||
| clipboard's contents. The promise is rejected if permission to access the clipboard is not granted. | ||
| * Ensure that raw formats are preserved |
There was a problem hiding this comment.
If a raw format doesn't map to a pre-defined (or custom electron application) MIME type, how would we expose the additional raw formats?
I believe on Windows you can use GetClipboardFormatName to get a string representation of the format (though annoyingly, for built-in formats, this returns an error because you're just supposed to know what those formats are 😅)
5 participants
This RFC outlines a rearchitecturing of the
clipboardmodule in Electron to improve alignment with the Clipboard API as specified by the W3C.📄 Read rendered document
coauthored with @codebytere.