Selections and the clipboard in X11
Format negotiation
Finding an acceptable format can be achieved by making multiple ConvertSelection requests until the format is accepted.
Writing a clipboard forwarder
Some selection targets (requests/formats) can return X resource IDs:
- "TARGETS" target returns a list of atom IDs. These should be converted to atom IDs on the other display.
- "PIXMAP" property type can theoretically be returned, though I doubt this is used. The forwarder should not try to forward this.
Do we need to whitelist property or target types? Sending resource IDs to another display is a potential confused deputy hazard.
Tasks
Write code to read and set the clipboard
Extend to handle ICCCM's INCR protocol
Write code to do a one-off forwarding of the clipboard
Implement symmetric (non-trusted-path) forwarding between 2 or more X displays
Implement asymmetric (trusted-path) forwarding between a real X display and an application's display
- Check that the application does not claim the selection on its own display when it shouldn't
- Ensure the forwarders forward data incrementally and don't try to send it in one big chunk
- Ensure the INCR protocol gets shut down and doesn't listen for data indefinitely
- Handle the case where the requester gives a property of None (for legacy clients; ICCCM deprecates this)
- Handle different target types properly
Hook up to Xpra
Send patch to Xpra mailing list
-- here
Fix problem that causes the event loop's assert_still_relevant() to fail, which can be triggered by holding down Ctrl-V. This does not happen with GlibEventLoop, only with the non-glib EventLoop. This is a problem with re-entrancy of the event loop.
There appears to be a race condition in the read or write side of the INCR protocol. test_write_and_read_clipboard has sometimes failed with an error such as AssertionError: ('Hellow orld 2\n', 'STRING') != ('Hello world 2\n', 'STRING')
Check whether the X server queues the PropertyNotify event before the reply from GetProperty. That seems unlikely.
- Write example clients that try to read or write the clipboard without being asked to, to demonstrate that the trusted-path mechanism works
References
ICCCM section 2, "Peer-to-Peer Communication by Means of Selections"
Spec for XFixes extension, which adds a SelectionNotify event which reports when a selection has changed
freedesktop.org clipboard spec; "This is not a formal specification, but explains our consensus on how the X clipboard works. Qt and GTK+ both follow this document" says the referring page
Xavier Toth is working on a clipboard manager for X on SELinux: gtk-devel-list post