Xpra: Ticket #2632: shadow cannot shift+arrow select

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



Tue, 10 Mar 2020 12:57:08 GMT - stdedos: attachment set


Tue, 10 Mar 2020 13:00:35 GMT - stdedos: description changed


Tue, 10 Mar 2020 13:00:58 GMT - stdedos: description changed


Wed, 11 Mar 2020 08:34:34 GMT - stdedos:

  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.


Wed, 11 Mar 2020 10:58:08 GMT - Antoine Martin: status changed

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.


Wed, 11 Mar 2020 12:45:41 GMT - Antoine Martin: owner, status, description changed

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:

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.


Thu, 12 Mar 2020 09:57:30 GMT - stdedos:

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


Thu, 12 Mar 2020 10:33:55 GMT - Antoine Martin: status changed; resolution set


Fri, 12 Jun 2020 17:53:18 GMT - themotoman: status changed; resolution deleted

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.


Fri, 19 Jun 2020 19:35:59 GMT - Stephane Gagnon:

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


Wed, 05 Aug 2020 21:24:00 GMT - jbylsma: owner, status, component, version changed; cc set

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.


Mon, 10 Aug 2020 23:34:37 GMT - Woongbin Kang:

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

Mon, 10 Aug 2020 23:35:00 GMT - Woongbin Kang: cc changed


Tue, 15 Sep 2020 10:26:36 GMT - Antoine Martin: owner, status changed

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.


Tue, 15 Sep 2020 11:07:43 GMT - Antoine Martin: status changed; resolution set

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


Tue, 15 Sep 2020 16:26:30 GMT - jbylsma:

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

Thank you!


Sat, 23 Jan 2021 05:56:34 GMT - migration script:

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