[RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Michal Suchanek]

On 22 February 2016 at 19:23, Carlos Garnacho <carlosg at gnome.org> wrote:
> Hi Michal,
>
> On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek <hramrach at gmail.com> wrote:
>> On 22 February 2016 at 15:57, Carlos Garnacho <carlosg at gnome.org> wrote:
>>> Hi Michal,
>>>
>>> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek <hramrach at gmail.com> wrote:
>>>> Hello,
>>>>
>>>> On 20 February 2016 at 01:31, Carlos Garnacho <carlosg at gnome.org> wrote:
>>>>
>>>>> +
>>>>> +  <description summary="Primary selection protocol">
>>>>> +    This protocol provides the ability to have a primary selection device to
>>>>> +    match that of the X server. This primary selection is a shortcut to the
>>>>> +    common clipboard selection, where text just needs to be selected in order
>>>>> +    to allow copying it elsewhere. The de facto way to perform this action
>>>>> +    is the middle mouse button, although it is not limited to this one.
>>>>> +
>>>>> +    Clients wishing to honor primary selection should create a primary
>>>>> +    selection source and set it as the selection through
>>>>> +    wp_primary_selection_device.set_selection whenever the text selection
>>>>> +    changes. In order to minimize calls in pointer-driven text selection,
>>>>> +    it should happen only once after the operation finished. Similarly,
>>>>> +    a NULL source should be set when text is unselected.
>>>>> +
>>>>> +    wp_primary_selection_offer objects are first announced through the
>>>>> +    wp_primary_selection_device.data_offer event. Immediately after this event,
>>>>> +    the primary data offer will emit wp_primary_selection_offer.offer events
>>>>> +    to let know of the mime types being offered.
>>>>> +
>>>>> +    When the primary selection changes, the client with the keyboard focus
>>>>> +    will receive wp_primary_selection_device.selection events. Only the client
>>>>
>>>> Why keyboard focus?
>>>>
>>>> Since paste is done mainly using mouse this has nothing to do with
>>>> keyboard focus.
>>>
>>> Doing this so allows us to behave just the same than we do with the
>>> core protocol selection, slightly divergent protocols make sharing
>>> code harder.
>>>
>>> Conceptually, it also makes some sense to me. I argue that a logical
>>> "key" focus is needed in compositors, even on lack of wl_keyboard
>>> capabilities. Things that IMO make sense to tie together in this
>>> focus, per-seat are:
>>> - wl_keyboard focus
>>> - wp_text_input focus
>>> - focus por (possibly several) pads/buttonsets
>>> - clipboard selection
>>> - primary selection
>>>
>>> Of course these are only guidelines, and compositors may attempt to
>>> implement split foci for these. But still, selection should be tied to
>>> some definite focus, the other option is broadcasting, and I'd very
>>> much prefer not to do that.
>>>
>>> I may try to change the wording just to suggest it's loosely attached
>>> to keyboard focus though.
>>
>> If you put an Insert sticker on your pad button and bind pasting to
>> that pad button and the pad focus is not tied to keyboard focus you
>> have potentially a problem there.
>
> Right, that's why I suggest having those reunited in a single logical
> focus. Anything else is plagued of corner cases.

That's totally not going to work. When  you have multiple touch panels
you can  touch multiple places. Are you proposing that on whichever
panel you happen to touch first locks the other panel from working or
on whichever panel you touch last steals the touch on the earlier
panel?

I do not think either is expected behaviour.

>
>>
>>>
>>>>
>>>>> +    with the keyboard focus will receive such events with a non-NULL
>>>>> +    wp_primary_selection_offer. Across keyboard focus changes, previously
>>>>> +    focused clients will receive wp_primary_selection_device.events with a
>>>>> +    NULL wp_primary_selection_offer.
>>>>> +
>>>>> +    In order to request the primary selection data, the client must pass
>>>>> +    a recent serial pertaining to the press event that is triggering the
>>>>> +    operation, if the compositor deems the serial valid and recent, the
>>>>
>>>> Why press event when it has an offer event to base the request on?
>>>>
>>>> There is no need to involve other unrelated events.
>>>
>>> IIRC The first protocol drafts attempted to limit the circumstances in
>>> which a client could read the primary selection. This is a change of
>>> approach.
>>>
>>>>
>>>> IMHO the fact that the application receives ANY input event suffices.
>>>> eg. a pointer entry event.
>>>
>>> Do you mean wl_pointer.enter should be enough to have the application
>>> read the primary selection? seems open to data leaks to me.
>>>
>>> This serial event is meant to check for user interaction rather than
>>> "any input event", so just focusing a client is not enough to have it
>>> retrieve the primary selection.
>>
>> And why is clicking enough and focusing not?
>>
>> Accidentally clicking an application can happen as much as
>> accidentally pointing at it.
>
> Citation needed :). Windows can be certainly arranged so that it's not
> possible to move the pointer between app A and B without going through
> a third application. The problem with doing this on pointer focus is

That can happen only with relative axis. With absolute axis you can
point anywhere anytime without going through anywhere else. Let's say
that for the sake of rodent users it is better to consider entry and
motion events insignificant.

> that situations like this come off the very nature of a 2D compositor.
> Tying this to user interaction kills most of the concerns here, the
> situation where the user accidentally clicks on an app that happens to
> be malicious and request the clipboard on any interaction should be
> unlikely enough, plus it'd make a lousy malicious app.
>
>> With touch interface it's pretty much the
>> same thing. With click-to-focus also. If you want to prevent data
>> leaks you can unmap windows that should not receive the paste or use a
>> compositor with per-application access policy for clipboards.
>
> Those are all compositor dependent policies, I think something should
> be done at the protocol level.
>
>>
>> So instead of saying that a button down event should trigger paste in
>> the protocol specification
>
> Nothing like that is mentioned. Wording is deliberately ambiguous as
> to which event triggers primary selection paste.
>
>> it is wiser to say that sending the paste
>> offer to a client can happen at the discretion of the compositor and
>> suggest some reasonable policy.
>
> What is unreasonable about serial checking?

How is the serial related to the paste? How is the application
supposed to pick serial so it can receive the paste? You can pick the
event which triggers the paste in the application logic. Will that
mean that when compositor fails to check events from a device (or the
application uses a device exclusively and possibly directly drives the
hardware) binding to some buttons will work and binding to other
buttons will fail?

Why is checking that the application can receive an offer when the
offer is sent not sufficient for the application to receive the paste?

When you want to prevent applications from receiving a paste in the
future you can always change the selection.

>
>>
>> Compositor should be free to implement any policy the author finds
>> reasonable including broadcast on selection change, point to paste,
>> button press to paste, and per-application different policies.
>
> So you want the protocol to be purposely ambigous on data leak situations?
>
> Let's take the most extreme case, primary selection can be broadcasted
> and clients can be free to read data right away. You've just allowed
> compositors to replicate all the flaws of X11 primary selection.

And you have allowed all the legacy X11 clients to perform flawlessly.

So it's fine to suggest reasonable default policy for compositor
implementors but it's also fine to allow for different policies.

I would not mandate broadcasting the selection changes
indiscriminately. However, if people are concerned about applications
that listen for the broadcasts in X11 land it should be possible to
set up special policy for them so they can receive the broadcasts in
Wayland as well. Similarly when an application is supposed to run
sandboxed and there is enough concern about information leak through
clipboard it should be possible to set up a policy for it to never
receive selection offers.

Thanks

Michal