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.
There was a problem hiding this comment.
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.
| * `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?
There was a problem hiding this comment.
Spec ( https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read#return_value) says clipboard.read returns:
A Promise that resolves with an array of ClipboardItem objects containing the clipboard's contents.
| * 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 😅)
There was a problem hiding this comment.
@itsananderson I think we could use the following mapping for raw formats:
electron application/osclipboard;format="OS CLIPBOARD NAME HERE"
eg
electron application/osclipboard;format="CF_TEXT".
Doing so would allow us to retain existing clipboard.read/clipboard.write functionality for raw formats without having to have custom mappings for specific formats.
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.