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.
erickzhao
added
final-comment-period
pending-review
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.