`wl-copy --foreground --paste-once` exits before copy and allows multiple pastes

[jpluscplusm]

Hi all 👋

I'm on a Chromebook (which may be relevant), and I observe this behaviour under (stable) Crostini:

$ wl-copy --version | head -1
wl-clipboard 2.0.0
$ foo=$RANDOM; echo $foo; echo $foo | wl-copy --foreground --paste-once
4016
$ wl-paste -n
4016
$ wl-paste -n
4016

NB there's no backgrounding going on - I hit [enter], once, exactly where you would assume: at the end of each $ prefixed line.

There seem to be a few disagreements with the manpage here, specifically that --foreground and --paste-once don't appear to do what the docs suggest they do.

I don't know enough about ChromeOS's clipboard treatment to do anything more than speculate, but if the OS' is perhaps constantly sucking up the Wayland clipboard's contents as soon as it changes, in order to provide/sync it to the "main" OS clipboard, then this might explain both misbehaviours.

As a datapoint, I see this when trying to talk to the primary clipboard:

$ echo 123 | wl-copy --foreground --paste-once --primary
The compositor does not seem to support primary selection

[bugaevc]

Hi! Yep, this sounds like your compositor is immediately taking over the selection.

There seem to be a few disagreements with the manpage here, specifically that --foreground and --paste-once don't appear to do what the docs suggest they do.

There's no disagreement with the docs, in fact the docs for --paste-once explicitly mention this possibility:

-o, --paste-once Only serve one paste request and then exit. Unless a clipboard manager specifically designed to prevent this is in use, this has the effect of clearing the clipboard after the first paste, <...>

And --foreground of course makes wl-copy not fork to background — you can verify yourself that it doesn't. But again, if a clipboard manager takes over the selection immediately, it's not going to make much of a difference, 'cause wl-copy is going to exit soon either way.

By the way, I believe that it's wrong for a clipboard manager to (forcibly) take over selection — instead, it should wait for the selection-owning client to exit, and only the substitute its copy of selection.

I'm not sure what else I can do you here...

[ghost]

The --paste-once option doesn't work as expected in sway 1.5.1

Since rofi-pass doesn't work on wayland, I sometimes use

pass shopping/amazon/myusername | wl-copy -o

to try and copy and paste my password once in a web browser. However, nothing happens when I try to paste it. If I paste the content on a terminal, that works as expected.

[bugaevc]

@objectivephoenix I don't think that is related to this issue at all. If you want to investigate what's going on in your case, please file a separate issue.

But I can tell you right away that certain clients are known to break with --paste-once (i.e. they require multiple pastes). To quote the man page:

Note that this may break pasting into some clients, in particular pasting into XWayland windows is known to break when this option is used.

This is not a bug in those clients: it's fine for them to expect that multiple pastes work; it's just that the paste-once mode is incompatible with them.

[ghost]

I'll create a separate issue for this then because I'm unable to use --paste-once when copying from and pasting to native wayland programs web browsers including Firefox, Chromium, and Brave, all of which are running as wayland programs.