Sway: [BUG] clipboard clears when source window is closed

[ngortheone]

sway 1.4
(no xwayland)

Description:
With any 2 windows open copy-paste between windows works until both windows stay open (e.g. terminal and browser)
As soon as window from where the copy operation was performed is closed clipboard contents are erased and it is not possible to paste anymore.

Steps to Reproduce

• Open browser and terminal (in my case Alacritty and Firefox)
• Copy text in one window, paste in another - witness that copy-paste works
• Copy some other text again and paste it several times into another window
• Close source window
• Try to paste to dest window - witness that paste operation pastes nothing.

[emersion]

This is by design. A clipboard manager is required for this to work.

[gandalf3]

Unfortunately clipboard managers break some applications under the current paradigm: https://github.com/yory8/clipman/issues/43#issuecomment-687562862

Is it possible support for clipboard persistence in sway could be reconsidered, seeing as it is currently impossible to get the same non-intrusive clipboard manager behavior as in X11?

[emersion]

X11 clipboard managers like KDE's do this:

• When a selection is set, they save its content, but don't overwrite it
• When a selection is un-set, they restore the content

Wayland is no different from X11.

[gandalf3]

But under wayland, what mechanism can be used to detect when the selection is unset? It seems that's the piece that's either missing or currently unknown to the clipman developers.

[emersion]

When the selection is reset, a NULL selection event is sent.

[gandalf3]

Oh, that's perfect, thanks! Now I think I see the relevant code in wl-paste.

[bugaevc]

X11 clipboard managers like KDE's do this:

• When a selection is set, they save its content, but don't overwrite it
• When a selection is un-set, they restore the content

Wayland is no different from X11.

@emersion you've previously (one, two) argued that it's not worth supporting that, and instead clipboard managers should just stick to taking over the selection immediately. If you've changed your mind, or if I misunderstood you in the first place, I'd be happy to discuss a protocol extension that would enable clipboard managers to implement the above 😀

When the selection is reset, a NULL selection event is sent.

As I pointed out elsewhere, a nil selection even is not enough to distinguish an explicitly unset selection from "lost" selection due to client exiting, nor is there any way for the clipboard manager to replace the selection atomically on client exit.

[emersion]

I'd be happy to discuss a protocol extension that would enable clipboard managers to implement the above

There's no need for any new protocol extension/update.

a nil selection even is not enough to distinguish an explicitly unset selection from "lost" selection due to client exiting, nor is there any way for the clipboard manager to replace the selection atomically on client exit.

What I described is the KDE clipboard manager behaviour. You're free to do something else.

[bugaevc]

You're free to do something else.

Indeed, you can implement something else. The problem is, you cannot do that same thing, if you want to — developers of external clipboard managers for Sway cannot implement the same behavior as the KDE behavior you described.

I can understand if your position is one shouldn't implement that, so adding APIs for it is not worth it. But that's not the same thing as saying that all the necessary APIs are there, and it's only the lack of will that's stopping clipman (or other clipboard managers) developers from implementing it.

There's no need for any new protocol extension/update.

The please describe how one would overcome the two limitations I've mentioned above 🙂

[emersion]

What limitations? We offer the same features and limitations as X11. At least the KDE clipboad manager folks don't need anything else.

[bugaevc]

What limitations?

There are two limitations; let me describe them again:

1. A clipboard manager needs to be able to reliably distinguish between the two following cases:

   • A client explicitly wants to unset/clear the selection (as in wl-copy --clear and set_selection(nil)), because it wants to get to the state where nothing is copied (so that "paste" menu items are displayed as inactive / greyed out and so on). This typically happens when working with sensitive data such as passwords, — in that case, the user wants to clear the data from the clipboard after they've used it (pasted it somewhere). In this case, a clipboard manager does not want to keep the previously copied data in the clipboard by providing their own data source. It might actually want to forget the previously copied data item, if it keeps history.
   • A client cannot maintain a data source (as in responding to wl_data_source.send and other events) anymore, but does not actually want to clear the clipboard. This typically happens when a client exits, but it may also happen when a client destroys a wl_data_source explicitly. In this case, the clipboard manager does want to keep the same data copied, as far as the user is concerned, by replacing/substituting the invalidated/destroyed source with its own copy.

   In wlr-data-control (and any other Wayland clipboard protocol I am aware of), these cases look identical to the clipboard manager: it gets a selection(nil) event (if it even receives any events because of keyboard focus), and that's it.

2. All this (noticing that a data source has been destroyed, replacing it with a copy maintained by the clipboard manager) needs to happen atomically. That is to say, other clients should be unable to experience any "intermediate state" where the old source is already gone, but the new one has not been submitted yet. They should not see the selection(nil) event (which means not delivering it to the clipboard manager itself either!), nor should they be able to set their own selection in between the old source disappearing and the clipboard manager taking over.

   If the clipboard manager is slow and takes several seconds to respond and you don't have the atomicity I just described, you may end up in situations where the exiting client's selection appears to be lost, only to reappear after a while, perhaps replacing another, newer selection — even more likely considering wlr-data-control doesn't associate set_selection() requests with serials, so the compositor has no way to detect if a request that arrived later has been "logically issued" earlier.

At least the KDE clipboad manager folks don't need anything else.

As the KDE clipboard persistence implementation (in Klipper) apparently also uses wlr-data-control, they also suffer from the same limitations:

• They don't seem to do anything special to guess which kind of "selection became nil" event they get, so they must suffer from the password manager vs dying client problem.
• They have recently discovered a variant of the second issue and tried to workaround it. And yes, they do say they need protocol improvements :smile:

cannot implement the same behavior as the KDE behavior you described

Correction: they can of course implement the same behavior since KDE is using wlr-data-control too; but they cannot implement it right (neither can KDE).

We offer the same features and limitations as X11.

Heh, X11 is not a particularly great gold standard to measure yourself against.

I know of Mutter's built-in clipboard manager, which (by virtue of being implemented inside the compositor) doesn't suffer from these problems. It correctly distinguishes between explicit clear vs destroyed selection, and (I believe) doesn't race with clients. If we want to match this with external clipboard managers, we need those protocol improvements I (and now KDE folks) keep mentioning.

See also