Add Set::exclude_from_history on linux by setting x-kde-passwordManagerHint by MrSmoer · Pull Request #155 · 1Password/arboard

MrSmoer · 2024-06-09T14:22:48Z

Fixes #129
Implements the Set::exclude_from_history method for linux.

I tested this on Plasma Wayland (they implement data control protocol) and X11 using this short rust program:

use arboard::Clipboard;
#[cfg(target_os = "linux")]
use arboard::SetExtLinux;
use std::{thread, time};

fn main() {
    let ten_millis = time::Duration::from_secs(10);
    let mut clipboard = Clipboard::new().unwrap();

    let d = clipboard.set().exclude_from_history().text("secretext");
    println!("hidden");
    thread::sleep(ten_millis);
    let d = clipboard.set().text("notsecrettext");
    println!("Not hidden");
    thread::sleep(ten_millis);
}

It did not display the secretext when pressing SUPER+V(opens klipper) but it did display the notsecrettext after 10 seconds, so it works as intended.

Gnome doesn't implement the data control protocol, but testing this change with wl-paste -l(probably falling back to the xserver clipboard stuff) seemed to work as well.

In contrast, using a gnome-shell-extension that hooks the the get_mimetypes-method from within the compositor for determinig the clipboard-data-content didn't seem to work properly.
With KeepassXC, which is just using Qt's-functions for handling the clipboard, this function behaved as expected on gnome from what I can tell.

I believe there is some deeper issue with the way gnome handles the clipboard in general, but I was not able to track down the specific difference between how Qt and arboard register their clipboard content to the compositor yet.

Thanks for reviewing this and have a nice Day!

complexspaces

Thank you for this PR! The structure of it looks good. My suggestions are just minor code quality ones.

I would like to test this out for myself (probably tomorrow) but I once this is cleaned up I think its ready.

src/platform/linux/mod.rs

src/platform/linux/wayland.rs

src/platform/linux/x11.rs

MrSmoer · 2024-06-20T08:32:52Z

I just noticed that it didn't work properly for me without wayland-data-control on plasma-wayland and sway in any version. It works properly with the option enabled.

... and I am not sure what to do about the CI-failure

complexspaces · 2024-06-20T15:57:57Z

I just noticed that it didn't work properly for me without wayland-data-control on plasma-wayland and sway in any version. It works properly with the option enabled.

on plasma-wayland and sway in any version. It works properly with the option enabled.

IIRC Plasma defaults to Wayland these days. Do you know if xwayland is running or installed? That would be needed for anything to happen if you aren't using the wayland-data-control feature. Regarding Sway, the same thing applies. I can certainly try to test this on Ubuntu where xwayland comes by default.

... and I am not sure what to do about the CI-failure

This looks like a new lint from the latest stable Rust release. At the top of the x11.rs file, inside the use std block, you'll need to delete usize from the list.

MrSmoer · 2024-06-25T22:34:03Z

I tried a little, and I wasn't able to properly solve the new CI-Issue

complexspaces · 2024-06-28T04:05:29Z

I spent several hours tonight trying to test this out, with mixed results. This seems to work fine in Plasma Wayland like you observed, but GNOME/Ubuntu were a mess. In my testing there, I used pano as a clipboard monitor.

GNOME apparently doesn't support the wayland extension that wl-clipboard-rs uses to put data on the clipboard, so arboard doesn't support wayland on GNOME for the time being, I guess. I believe that a proper-windowed app like KeePassXC uses a different protocol that actually works. I don't know off the top of my head what is is though.

Next testing in a GNOME X11 environment, I still couldn't get it to work with this PR. KeePassXC works fine. From what I can see, it works while the process using arboard is still running but once the arboard-specific X11 Window has been destroyed (when Clipboard is dropped) the clipboard manager saves the contents for some reason. I wasn't able to figure out the reason.

I'm not sure how to proceed here. It doesn't feel right to merge this when it can't be confirmed working-as-intended. I most likely will not have the time to continue digging into the X11 behavior in-depth because there's so many moving parts. Do you have interest in doing so @MrSmoer?

MrSmoer · 2024-07-02T12:10:15Z

I already started looking into the way the clipboard data flows, but could really wrap my head around it. The whole stack on gnome seems very convoluted to me, especially in connection with Xwayland and stuff. I dont have thaaat much time to spare, so this is going to be on my list of side-projects. I am not sure what would have to change in the ecosystem but I believe that it's just the way arboard interfaces with the x11-package or within the x11 rust-package. It would take some time :)

complexspaces · 2025-06-15T19:51:07Z

Hey again! I'm following up here with the intent to merge this branch now that I've resolved the last outstanding issue from my prior testing. I was doing some other clipboard stuff the last few weeks and ended up getting a lot of helpful context to investigate what was happening here. I apologize that this sat for so long but I didn't have any motivation or additional knowledge to revisit this until last week.

... I believe that a proper-windowed app like KeePassXC uses a different protocol that actually works. I don't know off the top of my head what is is though.

To quickly document this: GUI applications utilize the wl_data_device protocol for their clipboard operations, which is very distinct from what wl-clipboard-rs uses. GNOME has no intent to support the ext-data-manager extensions though, so my previous statement about GNOME incompatibility is going to be accepted as-is.

... From what I can see, it works while the process using arboard is still running but once the arboard-specific X11 Window has been destroyed (when Clipboard is dropped) the clipboard manager saves the contents for some reason. I wasn't able to figure out the reason.

This is what I spent more time digging into. After some testing, I narrowed it down to the way we were destroying the X Window when the last Clipboard is dropped. KeePassXC non-deterministically also displayed similar behavior if its process was suddenly terminated without the chance to cleanup. If arboard's window is destroyed while we still own the data, some X servers see that as a crash or something and forcibly retain the current selection's string contents.

I added a proper ownership relinquishment call and all the issues went away, so the GNOME clipboard manager extensions are no longer retaining excluded values. I decided to continue not doing this for non-excluded values though for two reasons:

Generally people really want these saved and get annoyed when things disappear, so this is another possible chance for the clipboard manager to do its job.
I don't want to risk a behavior regression for existing users right now 😅.

With that I believe we have proper coverage of X11 and Wayland clipboard manager exclusions now and am happy to merge this. For transparency I swapped around the commit authors on this branch due to the amount of time and debugging I put into the functionality. You're still obviously a co-author though because of the original contribution set.

Addresses 1Password#129 Co-authored-by: MrSmör <66489839+MrSmoer@users.noreply.github.com>

While there is no behavior difference, its more obviously correct if we only claim clipboard ownership _after_ we've written data and prepared to serve it.

complexspaces

Thanks again for starting on this! I also added support for excluding the other Set types and tested them on X11 with success.

MrSmoer · 2025-06-16T01:20:01Z

This is all very nice to see, thank you so much for revisiting this and all the debugging effort!!

For transparency I swapped around the commit authors on this branch due to the amount of time and debugging I put into the functionality. You're still obviously a co-author though because of the original contribution set.

Obviously, you did the huge part of the work with the actual engineering, so that is definitely the right thing to do ^^

Thank you so much for putting in the work and doing it the proper way!! ❤️

complexspaces · 2025-06-16T01:44:50Z

You're very welcome 😄.

I hope to have this out in a crates.io release soon once some other work wraps up.

complexspaces · 2025-06-28T00:02:23Z

This is now released as part of 3.6.0. Thanks again!

MrSmoer changed the title ~~Add exclude_from_history on linux by setting x-kde-passwordManagerHint~~ Add Set::exclude_from_history on linux by setting x-kde-passwordManagerHint Jun 11, 2024

complexspaces requested changes Jun 18, 2024

View reviewed changes

complexspaces force-pushed the master branch 5 times, most recently from da310d2 to fe41c16 Compare June 15, 2025 19:37

complexspaces force-pushed the master branch 2 times, most recently from 1855043 to 2384cb4 Compare June 15, 2025 20:45

complexspaces and others added 2 commits June 15, 2025 15:46

Add exclude_from_history on linux by setting x-kde-passwordManagerHint

69a6ff2

Addresses 1Password#129 Co-authored-by: MrSmör <66489839+MrSmoer@users.noreply.github.com>

Clarify ownership handling in selection data writing

44e89d9

While there is no behavior difference, its more obviously correct if we only claim clipboard ownership _after_ we've written data and prepared to serve it.

complexspaces force-pushed the master branch from 2384cb4 to 44e89d9 Compare June 15, 2025 20:46

complexspaces approved these changes Jun 15, 2025

View reviewed changes

complexspaces merged commit 7ea1cf2 into 1Password:master Jun 15, 2025
11 checks passed

complexspaces mentioned this pull request Jun 15, 2025

Fix incorrect implementation of clear on Linux #187

Merged

Conversation

MrSmoer commented Jun 9, 2024 • edited by complexspaces Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

complexspaces left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MrSmoer commented Jun 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

complexspaces commented Jun 20, 2024

Uh oh!

MrSmoer commented Jun 25, 2024

Uh oh!

complexspaces commented Jun 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrSmoer commented Jul 2, 2024

Uh oh!

complexspaces commented Jun 15, 2025

Uh oh!

complexspaces left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MrSmoer commented Jun 16, 2025

Uh oh!

complexspaces commented Jun 16, 2025

Uh oh!

complexspaces commented Jun 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MrSmoer commented Jun 9, 2024 •

edited by complexspaces

Loading

MrSmoer commented Jun 20, 2024 •

edited

Loading

complexspaces commented Jun 28, 2024 •

edited

Loading