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

[Michal Suchanek]

On 23 February 2016 at 20:03, Bill Spitzak <spitzak at gmail.com> wrote:
>
>
> On Tue, Feb 23, 2016 at 1:32 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>>
>> On 22 February 2016 at 19:23, Carlos Garnacho <carlosg at gnome.org> wrote:
>>
>> > 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.
>
>
> What? Absolutely this is the expected behavior. All the touch events go to
> the same client as the first touch event. For a more obvioius example,
> keystrokes and modifier states need to be sent to the client that you are
> pressing a mouse button on, even if the "keyboard focus" is some other
> client. There is only one focus for every single thing in the seat, the
> thing you are calling the "keyboard focus" is just a helper for what that
> focus is when no mouse buttons are held down.
>
> If you want them to go to different clients, put the touch panels on
> different seats.
>
> I fully agree that having "number of focus" != "number of seats" is going to
> be plagued with corner cases.
>
>> > 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.
>
>
> Who cares that it can't happen for absolute axis. It does happen for
> relative and those exist, even if you personally don't own a mouse.
>
>> > 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?
>
>
> It's really easy: the client sends the event it thinks triggered the paste.
> The compositor checks to make sure it is an event that really existed and
> that it counts as some active user interaction (ie it is a mouse or keyboard
> click). If the client sends a fake event or a focus-in event or anything
> else the compositor does not like, it will not get access to the clipboard
> data.
>
> The entire point of this is so that it would be possible to put sensitive
> data into the selection, because client cannot look at it without the user
> doing something obvious, such as clicking. Moving the mouse around should
> not cause clients to be able to look at the selection.
>
>> > 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.
>
>
> Except that the user has to be careful to not select passwords or banking
> numbers or anything else sensitive.
>
>> 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.
>
>
> It sounds like you are basically saying "paste does not work unless the
> client is specially privileged".

You are saying that also. You say that the client must have keyboard
focus to receive pastes.

What I add is that different policies might be viable and useful and
the protocol should not preclude the compositor from using different
policies.

>
> The reason for the serial is so that the compositor can decide whether to
> honor a request for the clipboard. You can still have specially privileged
> clients that can get it for any event, this is for "normal" clients so that
> paste works.

And since there is already policy in place that gives client(s) the
privilege to receive pastes it is redundant to check a client-supplied
random input event serial number when the client must already pass a
policy check to receive a paste offer in the first place. It might
also prevent policies that would allow pasting into applications that
do not use (compositor visible) input to trigger the paste.

>
> I think you may be fretting too much about X11 compatibility. I would just
> assume that X11 clients do not request the clipboard contents until after
> the event that triggers the paste. The X11 emulator can then guess the
> triggering event and send it to Wayland. There is no need to give X11
> clients more powers than Wayland ones.

It is irrelevant if the application is native Wayland application or a
X11 application. There is use for the clipboard change broadcasts in
X11 so they can be useful in similar ways in Wayland. Besides the
obvious clip managers there are eg. download managers that collect
subsequently selected URLs or remote control applications that forward
the clipboard to another machine.

Thanks

Michal