feat: add clipboard privacy options#49567
Conversation
| : ui::ClipboardBuffer::kCopyPaste; | ||
| } | ||
|
|
||
| [[nodiscard]] electron::api::Clipboard::PrivacyType GetClipboardPrivacyType( |
There was a problem hiding this comment.
I'm not a fan of using an impure function here, but it follows the pattern of GetClipboardBuffer.
|
|
||
| * `text` string | ||
| * `type` string (optional) - Can be `selection` or `clipboard`; default is 'clipboard'. `selection` is only available on Linux. | ||
| * `privacy` string (optional) - Can be `confidential`, `off-the-record`, or `none`. Default is `none`. |
There was a problem hiding this comment.
A note on approach:
As mentioned, I didn't want to patch Chromium, so I tied this to the two (seemingly) different options provided upstream. However, in practice, it seems there isn't much of a difference between the two in ordinary use. MarkAsConfidential() does add one more flag (kNoDisplay) to privacy_types_ than MarkAsOffTheRecord(). Though, after perusing the Chromium source code, it seems that flag is only used internally to diverge behavior in one very specific circumstance:
- When
kNoDisplayis present inprivacy_types_, Chromium merely sets a "flag" on the current clipboard item by way of anildata payload for a custom type. - That status is only checked by a
IsMarkedByOriginatorAsConfidential()function... - ...which is only ever used by code regarding the omnibox, which isn't a feature in Electron.
Perhaps privacy should just be a boolean. But I wonder if these two options will have more of a distinction upstream in the future.
There was a problem hiding this comment.
While I'm not an Electron maintainer, I do maintain arboard, a popular Rust library for clipboard interactions. Given everything I've seen on the desktop OSes, I don't believe there will be a difference between these any time soon. If something is marked as confidential every platform treats that as a "don't store" signal which results in it never appearing in any type of clipboard history functionality. I would strongly recommend keeping it simple with only one "level" for now.
There was a problem hiding this comment.
I appreciate your thoughtful response here. My wonder in my comment was based on the fact that the Chromium authors created these two distinctions in the first place. It does seem odd to me for them to have two functions that essentially do the same thing, although perhaps that can happen in such large projects and I don't know the history of these API's. I still fear the Chromium authors will do something in the future to further diverge these functions. I do agree with you, though, that using a boolean would be much simpler and would likely result in a nicer API.
| bookmark is unavailable. The `title` value will always be empty on Windows. | ||
|
|
||
| ### `clipboard.writeBookmark(title, url[, type])` _macOS_ _Windows_ | ||
| ### `clipboard.writeBookmark(title, url[, type][, privacy])` _macOS_ _Windows_ |
There was a problem hiding this comment.
I have some concern here about introducing another optional param here as our current API guidelines strongly prefer options objects where possible, but that'd require a breaking change. I'll bring this up in API this week.
There was a problem hiding this comment.
Yeah, I was trying to avoid a breaking change, but I do understand the benefit of an options object.
|
Deferring to the linked electron/rfcs#19 above |
Description of Change
This is my attempt to resolve #49466. I don't think it's quite ready, so
I'm opening it as a draft PR.I welcome comments and critiques to help refine this.I've added the ability to define the privacy of a write to the clipboard. While the original issue was requesting for the Apple platform, this PR should be cross-platform (to the extend that Chromium upstream actually uses the API's I'm depending on).
Upstream API's Used
(links pinned to Chromium 144.0.7559.60, the version used on the current major: Electron 40.0.0)
Our clipboard API uses the
ScopedClipboardWriterclass from upstream to manage writing to the clipboard. This class has a private member variable calledprivacy_types_that holds an enumeration of privacy settings for a write to the clipboard.Unfortunately, that member variable isn't writable directly, and the only mechanisms for manipulating it are the functions
MarkAsConfidential()andMarkAsOffTheRecord(). To avoid patching Chromium, I simply take these and expose them as mutually-exclusive values for aprivacyoption in theclipboardwriting API's in JS-land. I took the "privacy type" name for the name in of the enum in C++-land (even though it's now not really a one-to-one mapping) because I wasn't sure what else to call it.Local Testing
Final note: while this does compile and build, I haven't fully tested if the behavior actually works as I expect it to. I plan to do so soon, though.I have tested this briefly between my MacBook and my iPad and it seems to work well enough.
npm testpassesRelease Notes
Notes: Added clipboard privacy options to
clipboardwriting API's.