wlroots
wlroots copied to clipboard
xwayland clipboard sync and dnd
Whenever the wayland clipboard selection changes for a seat (selection-change event), we need to get the data source, read out the data from the fd and set the xwayland clipboard selection to its contents.
Whenever the X11 CLIPBOARD selection changes, we need to create a wayland data source, override the source methods, and set it on the seat.
A similar process will need to be done for the dnd selection (see the Weston xwayland implementation for guidance).
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/295
We should be careful not to do this if xwayland is not available. We should also probably only commit the sync when focus switches between wayland and xwayland views.
We should also probably only commit the sync when focus switches between wayland and xwayland views.
xclip
may be used in a wayland terminal, without switching focus between a wayland view and a xwayland one.
That's a good point, but it still presents a security concern. Let's make it toggleable.
Let's make it toggleable.
FYI, the wayland spec says to share the clipboard selection with windows only at the time they receive keyboard focus (and when the selection changes while a window has keyboard focus) which is the minimum amount of visibility required for a reasonably usable clipboard. So something like xclip is not possible using only core wayland protocols.
On X11, I think the clipboard is managed through acquiring a selection on the root window, but there would be no way to prove that the requester ever had keyboard focus.
I think we should find or create a standard for people who want something like xclip to work and understand the security implications of this. I find myself typing something like curl $(xclip -o)
sometimes.
FYI, the wayland spec says to share the clipboard selection with windows only at the time they receive keyboard focus (and when the selection changes while a window has keyboard focus) which is the minimum amount of visibility required for a reasonably usable clipboard. So something like xclip is not possible using only core wayland protocols.
I think we should do this. Not every tool is going to work straight up, especially if they pose a security threat.
I think we should find or create a standard for people who want something like xclip to work and understand the security implications of this. I find myself typing something like curl $(xclip -o) sometimes.
Sway, for one, now does this through IPC/swaymsg. I don't think a standard is necessary yet.
Anyone who wants to take this up should look at #440 for a poc.
References:
- XDND spec: https://www.freedesktop.org/wiki/Specifications/XDND/
- Mutter implementation: https://github.com/GNOME/mutter/blob/master/src/wayland/meta-xwayland-selection.c
Currently in sway using wlroots master, copy-pasting between XWayland and native Wayland clients does not always work.
what works:
- from evince (wayland) to geany (wayland)
- from xclip to firefox (xwayland)
- from geany (wayland) to firefox (xwayland)
what doesn't:
- copy/pasting from firefox (xwayland) to geany (wayland)
- the clipboard appears empty on pasting
- from geany (wayland) to
xclip -o -selection clipboard
- xclip outputs
Error: target STRING not available
- xclip outputs
- from
xclip -i -selection clipboard
to geany (wayland)- the clipboard appears empty on pasting
xclip
isn't supposed to work (it will only work if a xwayland window is focused).
Copy/pasting from firefox (xwayland) to geany (wayland) should work. Can you try other combinations (e.g. firefox to gedit)? In general copy-pasting from firefox to a wayland client works for me.
xclip
isn't supposed to work (it will only work if a xwayland window is focused).
Ah, ok, good to know, thanks.
wrt other combinations, indeed copy-pasting from firefox to textudio (qt, native wayland) works, so I guess this must be a geany issue.
For me, the only thing that doesn't work is copy-pasting from a native wayland application to another using xwayland. I tested with kitty, which can run natively on wayland or not:
- firefox (xwayland) -> kitty (xwayland): OK
- firefox (xwayland) -> kitty (wayland): OK
- kitty (xwayland) -> firefox (xwayland): OK
- ~kitty (wayland) -> firefox (xwayland): doesn't work~
Kitty-on-Wayland won't work if it's hidden. It's a bug that's been fixed in their master tree iirc.
this is relevant? https://github.com/bugaevc/wl-clipboard/issues/41
No.
Then we need a separate issue?
No, that isn't a compositor bug.
I've also noticed that I can't copy from a citrix session (unfortunately I have to use it for work) and firefox when moz_wayland_enabled is on, nor nomachine. I'm not sure if that's relevant to this issue and am mostly trying to gather information.