shadow cannot shift+arrow select

[totaam]

Issue migrated from trac ticket # 2632

component: keyboard | priority: minor | resolution: fixed

2020-03-10 12:57:00: stdedos created the issue

---

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

[[Image(xpra-cannot-shift-arrow-select-GTK_Keyboard_Test_2020-03-10_14-32-07.png)]]

"Xpra-Python3-x86_64_4.0-[r25568](../commit/879a9b9a0bf68b7e04127f8e0e93c05133ec4cdb)\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](../commit/879a9b9a0bf68b7e04127f8e0e93c05133ec4cdb) 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-25532 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*

[totaam]

2020-03-10 12:57:08: stdedos uploaded file xpra-cannot-shift-arrow-select-GTK_Keyboard_Test_2020-03-10_14-32-07.png (43.0 KiB)

[totaam]

2020-03-10 13:00:35: stdedos edited the issue description

[totaam]

2020-03-10 13:00:59: stdedos edited the issue description

[totaam]

2020-03-11 08:34:34: stdedos commented

---

1. Go in a text entering place (this "Add comment" will do also)
2. Write something
3. Press Shift+LeftArrow

Notice that your caret will have selected the last character you typed.

[totaam]

2020-03-11 10:58:09: antoine changed status from new to assigned

[totaam]

2020-03-11 10:58:09: antoine changed owner from antoine to antoine

[totaam]

2020-03-11 10:58:09: antoine commented

---

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.

[totaam]

2020-03-11 12:45:42: antoine changed status from assigned to new

[totaam]

2020-03-11 12:45:42: antoine changed owner from antoine to stdedos

[totaam]

2020-03-11 12:45:42: antoine edited the issue description

[totaam]

2020-03-11 12:45:42: antoine commented

---

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:

• r25606: don't change the modifiers list if the key we're pressing is going to be doing that - ie: when handling 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)
• r25607: allow NoSymbol to match without adjusting the shift modifier state
• r25608: also skip adjusting "mode switch" modifier for NoSymbol keys

Backporting all this was not fun: 25609.
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.

[totaam]

2020-03-12 09:57:30: stdedos commented

---

Verified as fixed: v3.0.7-25609 / post-#2631-client-version

[totaam]

2020-03-12 10:33:56: antoine changed status from new to closed

[totaam]

2020-03-12 10:33:56: antoine set resolution to fixed

[totaam]

2020-06-12 18:53:19: themotoman changed status from closed to reopened

[totaam]

2020-06-12 18:53:19: themotoman removed resolution (was fixed)

[totaam]

2020-06-12 18:53:19: themotoman commented

---

This is broken in the 4.0.2-26625-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-26630-2 on the server and it corrected the problem.

[totaam]

2020-06-19 20:36:00: sgagnon commented

---

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

[totaam]

2020-08-05 22:24:01: jbylsma changed status from reopened to new

[totaam]

2020-08-05 22:24:01: jbylsma changed component from client to keyboard

[totaam]

2020-08-05 22:24:01: jbylsma changed owner from stdedos to Antoine Martin

[totaam]

2020-08-05 22:24:01: jbylsma commented

---

I can also confirm that 4.0.2-26625-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:

• 4.0.1-26379-1 (latest stable 4.0.1)

• 4.0-26306-1 (latest stable 4.0)
• 4.0-20200505r26253-1 (latest beta 4.0.x to work)

I've attempted to use XPRA_SIMULATE_MODIFIERS=0 as a workaround suggested by #2632#comment:8 and #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-26625-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.

[totaam]

2020-08-11 00:34:37: wbkang commented

---

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](../commit/245927087b2f54d07d0bae73f2086b92faa2a50c)-1 --allow-downgrades

[totaam]

2020-09-15 11:26:37: antoine changed status from new to assigned

[totaam]

2020-09-15 11:26:37: antoine changed owner from Antoine Martin to antoine

[totaam]

2020-09-15 11:26:37: antoine commented

---

Bisecting - client version doesn't seem to make any difference - but Linux clients are not affected, only mswindows (and macos apparently?):

• 4.x 26379 OK
  Trunk:
• r27454 bad
• r26500 bad
• 26379 OK
• r26450 bad
• r26415 OK
• 26432 bad
• r26420 OK
• r26428 bad
• 26422 bad
• r26421 (no change from r26420) skipped
• r26420 OK

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

[totaam]

2020-09-15 12:07:43: antoine changed status from assigned to closed

[totaam]

2020-09-15 12:07:43: antoine set resolution to fixed

[totaam]

2020-09-15 12:07:43: antoine commented

---

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?)

[totaam]

2020-09-15 17:26:30: jbylsma commented

---

Confirmed working with a v4.1-27456 server on Ubuntu 20.04 LTS and a v4.1-r26987 client on MacOS.

Thank you!