Primary Selection

X has a generic selection mechanism which lets application own arbitrary selections and exchange data via them. This is used both for DND as well as for clipboards. Historically, there has been some confusion about the intended semantics of multiple clipboards in X, but http://www.freedesktop.org/wiki/Specifications/clipboards-extension-spec/ has emerged as a more or less universal consensus as to how things should work under X:

• the CLIPBOARD selection corresponds to explicit copy-paste actions of the user, normally bound to Ctrl-C/Ctrl-V
• the PRIMARY selection always corresponds to the currently selected text (or other data) in the focused application, and middle-click pastes the contents of the PRIMARY selection into any context (typically a text entry or editor)

The original Wayland protocol very intentionally supports only a single clipboard, which corresponds to the CLIPBOARD selection under X and works for explicit copy-paste. Among the arguments for eschewing the PRIMARY selection were:

• It makes it easy to unintentionally paste passwords, snippets of private conversations and other non-public information,
  • into online communication.
• security concerns with unexpected data stealing if the mere act of selecting a text fragment makes it available to all running applications

Additionally, reasons against keeping it:

• the middle click is a hard-to-discover easter egg
• there are few middle mouse buttons in the world

Still, many longterm X users have become reliant on this easter egg, and in particular terminal users have a hard time using the awkward Shift-Ctrl-C combination instead (since Ctrl-C is not available in terminals).

Therefore, we should consider bringing back primary selections in some form under Wayland, to ease the transition for long-term X users.

Constraints for a Wayland primary selection

We should address the security concerns by making sure that

• an app can only request the "selection" clipboard with a timestamp of a middle mouse button event sent to it, and only if the contents of the clipboard haven't changed since that middle mouse button event
• the feature is off by default and has to be enabled by the user

We should make sure that the feature is reliable

• the protocol should work across wayland implementations (weston, kwin, qt,...)
• xwayland needs to translate this to the PRIMARY selection transparently

Comments

11/9/2015 from Lyude: So one thing I'm not too keen on here is using an input event like a middle button click in order to request the contents of the front buffer on the protocol level. If we make a protocol for a PRIMARY buffer manager, we should be able to just send a wl_data_offer to the client during a scenario where we would want to allow it to paste from the primary buffer if it chooses to do so, e.g. when the user clicks the middle button. I'm going to try to come up with a rough draft of a protocol for this, I'll update this once I've got something.

Update: Here's that something: primary_selection_manager.txt One of the things that's been brought up about this is the fact I've chosen not to use the serials coming from the middle mouse button with this. My reasoning for doing so is what I stated above along with the fact that apparently it's quite common for users to remap this to a different key, so we don't really want to force the protocol to rely on any specific keybinding or mouse event. I'm willing to change this of course if others think using the serial from the middle mouse button would be a better idea.

Discussion

(Summary of a hallway discussion between Owen, Lyude and Matthias)

Protocol walkthrough:

• User selects text in application A
• Application A informs compositor that it takes ownership of the primary selection
• User middle-clicks over application B
• The compositor notices the middle click and sends a data offer for the primary selection to application B before the middle click event
• Application B requests the data from the compositor
• The compositor does what it usually does for data offers to get the data from A to B

We discussed binding the primary paste to a keyboard shortcut, but decided that it would be easier if the compositor had an out-of-band API for defining a keyboard shortcut that synthesizes a middle-click. If a keyboard shortcut is bound that way (from the keyboard panel in the control-center), the compositor will detect this key event and synthesize a middle-click (and do the other actions outlined above for actual middle-click events).

Note that while the walkthrough talks about selecting text, the protocol should be general to allow any content type for the primary selection.