e.g. Shift
+LeftArrow
will not select one character. This is a "recent" regression (I don't have a specific point in time; maybe it was working in 3.0.6).
"Xpra-Python3-x86_64_4.0-r25568\xpra_cmd" attach ssh://user@ip/0 --ssh="plink -ssh -agent" --modal-windows=no --opengl=no --min-quality=20 --desktop-scaling=0.75 2020-03-10 14:44:19,099 Xpra GTK3 client version 4.0-r25568 64-bit 2020-03-10 14:44:19,100 running on Microsoft Windows 10 2020-03-10 14:44:19,173 Warning: failed to import opencv: 2020-03-10 14:44:19,176 No module named 'cv2' 2020-03-10 14:44:19,176 webcam forwarding is disabled 2020-03-10 14:44:19,931 GStreamer version 1.16.2 for Python 3.8.2 64-bit 2020-03-10 14:44:20,188 keyboard layout code 0x409 2020-03-10 14:44:20,189 identified as 'United States - English' : us 2020-03-10 14:44:20,564 keyboard settings: layout=us 2020-03-10 14:44:20,566 desktop size is 1600x900 with 1 screen: 2020-03-10 14:44:20,567 Default (423x238 mm - DPI: 96x96) workarea: 1600x860 2020-03-10 14:44:20,567 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131) 2020-03-10 14:44:20,567 downscaled to 75%, virtual screen size: 2133x1200 2020-03-10 14:44:20,568 Default (423x238 mm - DPI: 128x128) workarea: 2133x1147 2020-03-10 14:44:20,568 (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 175x175) 2020-03-10 14:44:30,787 enabled remote logging 2020-03-10 14:44:30,794 Xpra GTK3 shadow server version 3.0.7-r25532 64-bit 2020-03-10 14:44:30,798 running on Linux Ubuntu 16.04 xenial 2020-03-10 14:44:30,800 remote desktop size is 6400x1440 2020-03-10 14:44:30,826 Attached to ip:22 2020-03-10 14:44:30,840 (press Control-C to detach)
Edit: Shift+!Home/!End don't work either; Shift+PgUp/PgDown works
Shift+LeftArrow
Notice that your caret will have selected the last character you typed.
Server side I see this:
do_get_keycode(16, 'Shift_L', True, ['shift', 'mod2'], 0)=50 (level=0, shift=True, mode=0) process_key_action(['key-action', 1, b'Shift_L', True, (b'shift', b'mod2'), 65505, b'', 16, 0]) server keycode=50 filtered_modifiers_set(['mod2'])={'mod2'} filtered_modifiers_set(['mod2'])={'mod2'} handle_key((1, True, 'Shift_L', 65505, 50, ['mod2'], True, True)) handle keycode pressing 50: key 'Shift_L' fake_key(50, True) set_keyboard_layout_group(0) config=KeyboardConfig(gb / / None), current keyboard group=0 do_get_keycode(37, 'Left', True, ['shift', 'mod2'], 0)=113 (level=0, shift=True, mode=0) process_key_action(['key-action', 1, b'Left', True, (b'shift', b'mod2'), 65361, b'', 37, 0]) server keycode=113 filtered_modifiers_set(['shift', 'mod2'])={'shift', 'mod2'} filtered_modifiers_set(['mod2'])={'mod2'} make_keymask_match(['mod2']) current mask: {'shift', 'mod2'}, wanted: {'mod2'}, ignoring=113/['Left'], keys_pressed={} 2020-03-11 17:41:47,112 keynames(shift)={'Shift_R', 'Shift_L'}, keycodes=[62, 50], nuisance=False, nuisance keys={'mod2', 'lock'} change_mask(remove) ['mod2'] modifier 'shift' using keycode 50 change_mask({'shift'}, False, remove) failed=[] change_mask(set(), True, add) failed=[] is_modifier(113) not found handle_key((1, True, 'Left', 65361, 113, ['mod2'], False, True)) handle keycode pressing 113: key 'Left' fake_key(113, True)
So we're unsetting the shift
modifier using Shift_L
(keycode 50) because we're trying to match modifiers=mod2
.
My guess is that the fix for #2301 makes us remove shift
from the modifiers so that we can trigger the Left
key with the correct level. And maybe I should not have backported it to v3 branch.
The fix for #2301 is clearly the cause of this problem.
Left
is at keycode 113 on my layout:
keycode 113 = Left NoSymbol Left NoSymbol Left
but there is a NoSymbol
for level=1 (when the shift
modifier present) so we unpress shift
to ensure we end up triggering Left
and not NoSymbol
. (see #2301 for details)
Updates:
Shift_L
, don't bother adjusting the shift
modifier state when locating the keycode (same as what we were already doing in make_keymask_match
)
NoSymbol
to match without adjusting the shift
modifier state
NoSymbol
keys
Backporting all this was not fun: r25609.
Fortunately, we already have XPRA_SIMULATE_MODIFIERS=0
so we can easily bypass all of these changes if they cause problems.
@stdedos: updated Xenial 3.0.7-RC server builds are available with this fix.
Verified as fixed: v3.0.7-r25609 / post-#2631-client-version
This is broken in the 4.0.2-r26625-1 branch. I was able to reproduce this bug using CLion editor, using Windows 10 as the client and Ubuntu 18.04 as the server. I installed 3.0.10-r26630-2 on the server and it corrected the problem.
I experience the same issue as themotoman with 4.0.2 running on the server (Ubuntu 18.04) and 4.0.1 on the client (Windows 10, 20.04).
I can also confirm that 4.0.2-r26625-1 (latest stable) and 4.1-20200801r27044-1 (latest 4.x beta) cannot use Shift Arrows on Ubuntu 20.04 LTS (Focal), connecting with MacOS client v4.1-r26987.
I can confirm that the following are able to select text with the same server/client configuration:
I've attempted to use XPRA_SIMULATE_MODIFIERS=0
as a workaround suggested by ticket:2632#comment:8 and ticket:2702#comment:1 but there appeared to be no change.
The keyboard state looks similar to the original two posted images in the ticket, where Shift is released before the arrow is pressed and reactivated after the arrow is released. I can provide the screenshots if it is helpful.
The diff against the relevant keyboard debug appears to have the modifiers swap. I'm unsure if that's impactful.
# 4.0.2-r26625-1 Server keyboard debug, pressing Shift+Left, works filtered_modifiers_set(['shift', 'mod2'])={'shift', 'mod2'} filtered_modifiers_set(['mod2'])={'mod2'} make_keymask_match(['mod2']) current mask: {'shift', 'mod2'}, wanted: {'mod2'}, ignoring=113/['Left'], keys_pressed={62: 'Shift_R'}
# 4.1-20200801r27044-1 Server keyboard debug, pressing Shift+Left, does not work filtered_modifiers_set(['shift', 'mod2'])={'mod2', 'shift'} filtered_modifiers_set(['mod2'])={'mod2'} make_keymask_match(['mod2']) current mask: {'mod2', 'shift'}, wanted: {'mod2'}, ignoring=113/['Left'], keys_pressed={62: 'Shift_R'}
Additionally, 4.1-20200801r27044-1 has client debug output that may be relevant
# 4.1-20200801r27044-1 Server keyboard debug, pressing Shift+Left, does not work 2020-08-05 16:27:15,316 client 2 @30.391 mask_to_names(<flags GDK_SHIFT_MASK of type Gdk.ModifierType>)=['shift', 'mod2'] swap_keys=False, modmap={<flags GDK_SHIFT_MASK of type Gdk.ModifierType>: 'shift', <flags GDK_LOCK_MASK of type Gdk.ModifierType>: 'lock', <flags GDK_SUPER_MASK of type Gdk.ModifierType>: 'mod3', <flags GDK_HYPER_MASK of type Gdk.ModifierType>: 'mod4', <flags GDK_META_MASK of type Gdk.ModifierType>: 'mod1', <flags GDK_CONTROL_MASK of type Gdk.ModifierType>: 'control'}, num_lock_state=True, num_lock_modifier=mod2 2020-08-05 16:27:15,316 client 2 @30.392 parse_key_event(<Gdk.EventKey object at 0x10dd07040 (void at 0x7fad8fa3ebd0)>, False)=<GTKKeyEvent object, contents: {'modifiers': ['shift', 'mod2'], 'keyname': 'Left', 'keyval': 65361, 'keycode': 123, 'group': 0, 'string': '', 'pressed': False}> 2020-08-05 16:27:15,316 client 2 @30.392 handle_key_action(ClientWindow(2), <GTKKeyEvent object, contents: {'modifiers': ['shift', 'mod2'], 'keyname': 'Left', 'keyval': 65361, 'keycode': 123, 'group': 0, 'string': '', 'pressed': False}>) wid=2 2020-08-05 16:27:15,317 client 2 @30.392 key_handled_as_shortcut(ClientWindow(2), 'Left', ['shift', 'mod2'], False) shortcuts_enabled=True, shortcuts=None 2020-08-05 16:27:15,317 client 2 @30.392 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['shift', 'mod2'], 'keyname': 'Left', 'keyval': 65361, 'keycode': 123, 'group': 0, 'string': '', 'pressed': False}>)
If you would rather keep this for 3.x and address 4.x work in a new ticket, I will revert my changes and and open a new ticket.
I was able to at least rollback to a previous version by forcing a specific version like this on Ubuntu:
sudo apt install -y xpra=4.0-r26309-1 --allow-downgrades
Bisecting - client version doesn't seem to make any difference - but Linux clients are not affected, only mswindows (and macos apparently?):
Trunk:
So r26422 is bad. (was needed for #2769)
And we have a viable workaround already: launch the xpra server with XPRA_XKB=0
to revert to the old key mapping code.
Working log sample with XPRA_XKB=0
:
will try levels: [1, 5, 0, 4, 3, 7, 2, 6] do_get_keycode(40, 'Down', True, ['shift', 'mod2', 65364, 0)=116 (level=0, shift=True, mode=0, keysyms=['Down', '', 'Down']) fake_key(116, True)
Failing log sample with XPRA_XKB=1
:
will try levels: [1, 5, 0, 4, 3, 7, 2, 6] do_get_keycode(40, 'Down', True, ['shift', 'mod2', 65364, 0)=116 (level=0, shift=True, mode=0, keysyms=['Down']) removing 'shift' from modifiers filtered_modifiers_set(['shift', 'mod2'])={'shift', 'mod2'} filtered_modifiers_set(['mod2'])={'mod2'} make_keymask_match(['mod2']) current_mask: {'shift', 'mod2'}, wanted: {'mod2'}, ignoring=116/'Down', keys_pressed={} fake_key(116, True)
So we find that the Down
key has the following keysyms: ("Down", "", "Down")
whereas with XKB we get a single keysym: ("Down")
.
And so we chose to remove shift
to match the key level.
r27455 fixes this by taking the same shortcut as before when there are no other keysyms. I will backport. (and maybe we should do this for all cases where there aren't enough keysyms? with xkb mode only?)
Confirmed working with a v4.1-r27456 server on Ubuntu 20.04 LTS and a v4.1-r26987 client on MacOS.
Thank you!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2632