xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 7 days ago

Last modified 7 days ago

#2632 closed defect (fixed)

shadow cannot shift+arrow select

Reported by: stdedos Owned by: Antoine Martin
Priority: minor Milestone: 4.0
Component: keyboard Version: 4.0.x
Keywords: Cc: jbylsma, Woongbin Kang

Description (last modified by Antoine Martin)

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

Attachments (1)

xpra-cannot-shift-arrow-select-GTK_Keyboard_Test_2020-03-10_14-32-07.png (43.0 KB) - added by stdedos 7 months ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 months ago by stdedos

Description: modified (diff)

comment:2 Changed 7 months ago by stdedos

Description: modified (diff)

comment:6 in reply to:  5 Changed 7 months ago by 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.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 7 months ago by Antoine Martin

Status: newassigned

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.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:8 Changed 7 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to stdedos
Status: assignednew

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

comment:9 Changed 6 months ago by stdedos

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

Last edited 6 months ago by stdedos (previous) (diff)

comment:10 Changed 6 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

comment:11 Changed 3 months ago by themotoman

Resolution: fixed
Status: closedreopened

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.

comment:12 Changed 3 months ago by 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).

comment:13 Changed 7 weeks ago by jbylsma

Cc: jbylsma added
Component: clientkeyboard
Owner: changed from stdedos to Antoine Martin
Status: reopenednew
Version: 3.0.x4.0.x

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:

  • 4.0.1-r26379-1 (latest stable 4.0.1)
  • 4.0-r26306-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 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.

comment:14 Changed 6 weeks ago by 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

comment:15 Changed 6 weeks ago by Woongbin Kang

Cc: Woongbin Kang added

comment:16 Changed 7 days ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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.

Last edited 7 days ago by Antoine Martin (previous) (diff)

comment:17 Changed 7 days ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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

comment:18 Changed 7 days ago by jbylsma

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

Thank you!

Note: See TracTickets for help on using tickets.