Xpra: Ticket #1293: Release keys when loosing focus

If I switch away from xrpa windows to another desktop with shortcut (i.e. with Super+2 in my case) and then return back to xpra window using mouse, Super key would still be pressed on server, until some key event is sent to xpra window. Client should release all key presses when its windows loose focus.

Sun, 28 Aug 2016 14:27:20 GMT - Antoine Martin: status changed

That should already be the case, can you attach a -d keyboard debug output to this ticket? And include more keyboard debugging information (layout, etc), see wiki/Keyboard - include desktop environment, etc..

Sun, 28 Aug 2016 14:53:11 GMT - psycho_zs:

Output attached. What I did: in a leafpad window (remote) typed 'qwerty', switched away using shortcut, returned using mouse, typed 'u' nothing happened, typed 'u' again, it typed.

Sun, 28 Aug 2016 15:01:10 GMT - Antoine Martin: owner, status changed

Please see comment:1 for providing more details, and in particular wiki/Keyboard, are you using keyboard sync?

I can see a key event for Super_L, but rightly or wrongly the key is not found in the modifiers list (modifiers': []). Maybe the client debug output would help.

The only other option would be to always unpress all the keys (but not modifiers?) whenever xpra windows are not in focus.

Sun, 28 Aug 2016 15:39:17 GMT - psycho_zs:

layouts: us,ru. Both client and server switched to us in this test.

Toggling keyboard sync does not affect the outcome.

setxkbmap -print is identical on client machine and in xpra session:

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete+ledscroll(group_lock)"	};
	xkb_symbols   { include "pc+us+ru:2+inet(evdev)+group(alt_shift_toggle)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc105)"	};

setxkbmap -query:

rules:      evdev
model:      pc105
layout:     us,ru
variant:    , # this line does not present in xpra session, but present local
options:    grp_led:scroll,terminate:ctrl_alt_bksp,grp:alt_shift_toggle,terminate:ctrl_alt_bksp,grp_led:scroll

xkbprint -label name $DISPLAY returns nothing.

Additional info will be in file soon.

Sun, 28 Aug 2016 15:39:47 GMT - psycho_zs: attachment set

Sun, 28 Aug 2016 15:40:54 GMT - psycho_zs:

releasing keys when no xpra window has focus seems logical to me.

Sun, 28 Aug 2016 15:49:04 GMT - Antoine Martin:

releasing keys when no xpra window has focus seems logical to me.

If we have to, we will - but I fear that this could well cause us some new problems..

As expected, the key is defined as a modifier:

mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)

So I'm really not sure why it isn't included in the list of modifiers as "mod4" with the key events.

Can you run the keyboard test script and see if it recognises the key as a modifier: browser/xpra/trunk/src/xpra/gtk_common/gtk_view_keyboard.py. The modifiers are shown at the top and key events below. (it should already be included when you install xpra)

Sun, 28 Aug 2016 16:10:16 GMT - psycho_zs:

Test script's window shows it as modifier, mod4. It disappears when I switch away from this window with shortcut, but after returning to it with mouse, it not react or list the next key press, only the one after that.

Tue, 06 Sep 2016 06:37:10 GMT - Antoine Martin:

I think I've got this one: when we click away from the window, we already unpress all the keys (you can see this by running the server with "-d keyboard,focus"), but then the client window has its attributes changed (ie: focus window attribute gets unset) so we send a configure-window packet back to the server, and this packet includes the modifiers... so we then re-set them! r13575 should fix this.

@psycho_zs: please close if this works for you.

Tue, 06 Sep 2016 18:35:22 GMT - psycho_zs:

latest build (r13590) fails to launch, seemingly because it tries to resolve config directory as /home/user/~/.xpra

Or rather it adds pwd to the path:

$ xpra start :100
using systemd-run to wrap 'start' server command
'systemd-run' '--scope' '--user' '/usr/bin/xpra' 'start' ':100'
Running scope as unit: run-rcd50ed61bbe642a5af3428869fba6fb1.scope
[Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra'
xpra main error:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 124, in main
    return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 1133, in run_mode
    return run_server(error_cb, options, mode, script_file, args, current_display)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/server.py", line 1017, in run_server
    logfd = open_log_file(log_filename0)
  File "/usr/lib/python2.7/dist-packages/xpra/scripts/server.py", line 554, in open_log_file
    return os.open(logpath, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o666)
OSError: [Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra/:100.log'

Wed, 07 Sep 2016 03:05:06 GMT - Antoine Martin:

OSError: [Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra/:100.log'

That's odd, probably caused by r13507, does r13593 help? If not, please include the build and install commands that you've used as part of those paths are generated at build time.

Wed, 07 Sep 2016 03:46:54 GMT - psycho_zs:

r13593 works.

But the first key pressed after returning to window is still ignored.

Attaching keyboard.log: pressed 1 2 3 4, switched away with Super+1, returned with mouse, pressed 5 two times, only second one is printed.

Wed, 07 Sep 2016 03:47:13 GMT - psycho_zs: attachment set

Wed, 07 Sep 2016 04:27:44 GMT - Antoine Martin:

The client side looks fine (the events are seen and sent without any modifiers), can you please post the server side "-d keyboard,focus" log? What desktop environment do I need to reproduce this?

Wed, 07 Sep 2016 04:49:37 GMT - psycho_zs: attachment set

Wed, 07 Sep 2016 04:54:16 GMT - psycho_zs:

I use openbox, shorcuts Super+[1-5] to switch between desktops.

Another update: it happens only when there are more than one window in Xpra session, and when returning to the same window you left. In the latest test I had two leafpad windows. First keypress after returning to window is at 07:45:15 in the log.

Wed, 07 Sep 2016 04:56:52 GMT - psycho_zs: attachment set

Wed, 07 Sep 2016 05:00:48 GMT - psycho_zs:

Added keyboard_server_2.log​, with focus debug this time. I did two tests series in this session: first with single leafpad window: 1,2,3, switch away, back, 4, 4. It worked. Then opened the second leafpad window, did the same, first "4" was ignored. See around 07:55:15 for second return.

Wed, 07 Sep 2016 09:08:02 GMT - Antoine Martin:

I think I can see what is going wrong here: r231 (a very very old changeset, see ticket:138#comment:11 for details) makes us call the focus change method via a main loop callback, and so our keyboard call to fake_key(13, True) happens just before the focus event... and lands on the root window instead of the window we want.

Partial revert of r231 applied in r13600. I've tested with win32 clients and "git gui" as per #138 and this does not seem to cause a regression (yet), so it looks like ticket:138#comment:15 was correct and the proper fix for the focus issue was r2003.

@psycho_zs: does that work for you?

Wed, 07 Sep 2016 09:37:42 GMT - psycho_zs: status changed; resolution set

This issue seems to be resolved. Thank you!

Sat, 23 Jan 2021 05:20:19 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1293