xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1293 closed defect (fixed)

Release keys when loosing focus

Reported by: psycho_zs Owned by: psycho_zs
Priority: minor Milestone: 1.0
Component: client Version: trunk
Keywords: focus keyboard release Cc:

Description

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.

Attachments (4)

keyboard.txt (83.8 KB) - added by psycho_zs 3 years ago.
keyboard.log (59.7 KB) - added by psycho_zs 3 years ago.
keyboard_server.log (483.0 KB) - added by psycho_zs 3 years ago.
keyboard_server_2.log (488.9 KB) - added by psycho_zs 3 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 3 years ago by Antoine Martin

Status: newassigned

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..

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs
Status: assignednew

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.

comment:4 Changed 3 years ago by 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.

Changed 3 years ago by psycho_zs

Attachment: keyboard.txt added

comment:5 Changed 3 years ago by psycho_zs

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

comment:6 Changed 3 years ago by 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)

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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
^R
using systemd-run to wrap 'start' server command
'systemd-run' '--scope' '--user' '/usr/bin/xpra' 'start' ':100'
Running scope as unit: run-rcd50ed61bbe642a5af3428869fba6fb1.scope
^R
[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'

Last edited 3 years ago by psycho_zs (previous) (diff)

comment:10 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by 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.

Changed 3 years ago by psycho_zs

Attachment: keyboard.log added

comment:12 Changed 3 years ago by 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?

Changed 3 years ago by psycho_zs

Attachment: keyboard_server.log added

comment:13 Changed 3 years ago by 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.

Changed 3 years ago by psycho_zs

Attachment: keyboard_server_2.log added

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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?

comment:16 Changed 3 years ago by psycho_zs

Resolution: fixed
Status: newclosed

This issue seems to be resolved. Thank you!

Note: See TracTickets for help on using tickets.