[PATCH v2] input: don't send to clients key events eaten by bindings

[Bill Spitzak]

On 11/06/2014 11:55 AM, Giulio Camuffo wrote:
> 2014-11-06 21:48 GMT+02:00 Bill Spitzak <spitzak at gmail.com>:
>>
>>
>> On 11/06/2014 09:55 AM, Giulio Camuffo wrote:
>>>
>>> weston key bindings are supposed to eat the key events, and not pass it
>>> on to clients, and indeed the wl_keyboard.key event is not sent. But
>>> we must also not put the key in the keys array to pass to client with
>>> the wl_keyboard.enter event, or else we may send the 'eaten' one too.
>>> In the case of a key binding hiding a surface having the keyboard focus,
>>> the shell may decide to give the focus to another surface, but that will
>>> happen before the key is released, so the new focus surface will receive
>>> the code of the bound key in the wl_keyboard.enter array.
>>
>>
>> Why can't the client distinguish this from an actual key press after it got
>> the focus?
>
> It may, but that's not the point. The key was eaten by the compositor
> binding, it must not be sent to the client.

The key is not being "sent". A map of what keys are pushed down right 
now is what is sent.

The user certainly expects the client to act like the key is held down 
for shift keys, and because of this you are sending an inconsistent 
shift state that does not match the key-down state.

What if a client considers the key that triggered the event to be a 
modifier and acts different if held down? The user is certainly holding 
it down, so the client will not act correctly if it does not know this.

More of a concern, what if the user accidentally thinks they have to 
hold down some unrelated key like 'x'? This will mean that the x will 
repeat, because it was not "used", but the user certainly cannot see 
this. Instead, all keys pressed before the action that transferred 
keyboard focus must act identically, whether or not they were a command.