Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can not type "less than" character (<) in HTML5 client #1902

Closed
totaam opened this issue Jul 5, 2018 · 15 comments
Closed

can not type "less than" character (<) in HTML5 client #1902

totaam opened this issue Jul 5, 2018 · 15 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jul 5, 2018

Issue migrated from trac ticket # 1902

component: html5 | priority: major | resolution: fixed | keywords: input keyboard

2018-07-05 12:14:02: matteoipri created the issue


I found this issue when running xpra in a Docker container with Ubuntu 17.10 artful and using the HTML5 client. This bug is present in both version of xpra and only in HTML5 client.

If I try to type the "less than" character (<) pressing "shift+," when using the HTML5 client, I get the "greater than" character (>).
This happens on both stable and beta HTML5 clients, but not with the desktop client. My keyboard has the US layout and has 104 keys. In the logs I see that the "us" layout is chosen by xpra and that the ctrl key press is recognized by xpra.
Other keys with issues are the 4 in the top right corner of the keyboard (top right corner of the numpad): /, , - and +. These four are mapped to the similar keys in the main part of the keyboard, thus when I press "" I get "8" and I have to press "shift+" to get the "".

I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version 2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra X11 version 2.4-19803 64-bit as of this writing) and I found some bugs when comparing the HTML5 client to the Xpra desktop client I use on my Arch Linux running PC.

The Docker images are based on Ubuntu 17.10 artful and I attach the Dockerfiles so that my experiments can be reproduced.

To build the images, I run the following commands:

sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/ 
sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta path/to/xpra/

To run the containers, I enter the following:

sudo docker run --interactive --tty --rm -p 8080:8080 xpra
sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta
@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 12:14:12: matteoipri uploaded file Dockerfile (1.6 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 12:14:28: matteoipri uploaded file Dockerfile-beta (1.7 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

Can you please attach the server log and an xpra info snapshot of when the html5 client is connected? (more general keyboard bug reporting guidelines here: Keyboard)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 15:42:14: matteoipri uploaded file xpra-info.txt (98.5 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 15:42:50: matteoipri uploaded file xpra-stable-server-log.txt (4.8 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 15:43:15: matteoipri uploaded file xpra-stable-info.txt (97.1 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 15:43:58: matteoipri uploaded file xpra-stable-xev.png (363.0 KiB)

screenshot of xev output when trying to type greater and lesser than
xpra-stable-xev.png

@totaam
Copy link
Collaborator Author

totaam commented Jul 5, 2018

2018-07-05 15:47:15: matteoipri commented


I attached some dumps.
I am not able to delete the file "xpra-info.txt" that was dumped in a previous run, while all other file are from the same run.
Here are the two smaller dumps:

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us

@totaam
Copy link
Collaborator Author

totaam commented Jul 9, 2018

See also #1898

@totaam
Copy link
Collaborator Author

totaam commented Sep 16, 2018

2018-09-16 12:01:20: antoine commented


I can reproduce. The problem does not occur when selecting a UK layout in the advanced options.

Here's the keyboard debug log for Shift + ,:

client keyboard processKeyEvent( true ,  [object KeyboardEvent] ) key= ShiftLeft keycode= 16
client keyboard passing clipboard modifier key event to browser: Shift_L
client keyboard key-action,1,Shift_L,true,shift,mod2,16,Shift,16,0
set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0
get_keycode(16, Shift_L, ('shift', 'mod2')) keyname+keycode lookup: 50
process_key_action(['key-action', 1, 'Shift_L', 1, ['shift', 'mod2'], 16, 'Shift', 16, 0]) server keycode=50
filtered_modifiers_set(['mod2'])=set(['mod2'])
modifier 'shift' ignored (in ignored keynames=set(['Shift_L', 'Shift_R']))
filtered_modifiers_set(('shift', 'mod2'))=set(['mod2'])
handle_key(1,1,Shift_L,16,50,('shift', 'mod2')) keyboard_sync=True
handle keycode pressing    50: key 'Shift_L'
fake_key(50, True)
client keyboard processKeyEvent( true ,  [object KeyboardEvent] ) key= Comma keycode= 188
set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0
client keyboard key-action,1,less,true,shift,mod2,188,<,188,0
get_keycode(188, less, ('shift', 'mod2')) keyname lookup: 94
process_key_action(['key-action', 1, 'less', 1, ['shift', 'mod2'], 188, '<', 188, 0]) server keycode=94
filtered_modifiers_set(['mod2', 'shift'])=set(['shift', 'mod2'])
filtered_modifiers_set(('shift', 'mod2'))=set(['shift', 'mod2'])
handle_key(1,1,less,188,94,('shift', 'mod2')) keyboard_sync=True
is_modifier(94) not found
handle keycode pressing    94: key 'less'
fake_key(94, True)
client keyboard processKeyEvent( false ,  [object KeyboardEvent] ) key= Comma keycode= 188
set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0
client keyboard key-action,1,less,false,shift,mod2,188,<,188,0
get_keycode(188, less, ('shift', 'mod2')) keyname lookup: 94
process_key_action(['key-action', 1, 'less', 0, ['shift', 'mod2'], 188, '<', 188, 0]) server keycode=94
filtered_modifiers_set(['mod2', 'shift'])=set(['shift', 'mod2'])
filtered_modifiers_set(('shift', 'mod2'))=set(['shift', 'mod2'])
handle_key(1,0,less,188,94,('shift', 'mod2')) keyboard_sync=True
is_modifier(94) not found
handle keycode unpressing  94: key 'less'
fake_key(94, False)
client keyboard processKeyEvent( false ,  [object KeyboardEvent] ) key= ShiftLeft keycode= 16
client keyboard passing clipboard modifier key event to browser: Shift_L
client keyboard key-action,1,Shift_L,false,mod2,16,shift,16,0
set_keyboard_layout_group(0) config=KeyboardConfig(us / None / None), current keyboard group=0
get_keycode(16, Shift_L, ('mod2',)) keyname+keycode lookup: 50
process_key_action(['key-action', 1, 'Shift_L', 0, ['mod2'], 16, 'shift', 16, 0]) server keycode=50
modifier 'shift' ignored (in ignored keynames=set(['Shift_L', 'Shift_R']))
filtered_modifiers_set(['mod2', 'shift'])=set(['mod2'])
filtered_modifiers_set(('mod2',))=set(['mod2'])
handle_key(1,0,Shift_L,16,50,('mod2',)) keyboard_sync=True
handle keycode unpressing  50: key 'Shift_L'
fake_key(50, False)

From the top:

  • Shift_L is correct:
$ DISPLAY=:2 xmodmap -pm | grep Shift_L
shift       Shift_L (0x32),  Shift_R (0x3e)
$ DISPLAY=:2 xmodmap -pke | grep Shift_L
keycode  50 = Shift_L NoSymbol Shift_L
  • mod2 can be ignored:
$ DISPLAY=:2 xmodmap -pm | grep mod2
mod2        Num_Lock (0x4d)
  • the packet for < looks correct:
['key-action', 1, 'less', 1, ['shift', 'mod2'], 188, '<', 188, 0] server keycode=94

But the key that we find in the keymap is not the right one:

$ DISPLAY=:2 xmodmap -pke | grep less
keycode  59 = comma less comma less
keycode  94 = less greater less greater bar brokenbar bar

We should be using 59 and not 94.
That's because we match the keycode by keysym, not taking into account the modifier state.

Let's fix this then I'll take a look at the other keys.

@totaam
Copy link
Collaborator Author

totaam commented Sep 16, 2018

2018-09-16 12:46:44: antoine commented


Here's the key mapping phase:

XPRA_DEBUG_KEYSYMS=less xpra start ...
setting keyboard layout to 'us'
set_keycode_translation: find_keycode(60, 'less', 0) x11 keycodes=(59, 94)
x11 keycode 59: ['comma', 'less', 'comma', 'less']
x11 keycode 94: ['less', 'greater', 'less', 'greater', 'bar', 'brokenbar', 'bar']
set_keycode_translation: find_keycode(60, 'less', 0)=94 (exact index match)

Patch to follow.

@totaam
Copy link
Collaborator Author

totaam commented Sep 16, 2018

2018-09-16 12:47:29: antoine uploaded file extra-keysyms.patch (3.2 KiB)

add extra keysyms so we can match them precisely, including the shift level

@totaam
Copy link
Collaborator Author

totaam commented Sep 16, 2018

2018-09-16 17:36:43: antoine commented


Patch merged in r20420 with one important change: the order of the (keysym, level) pair is reversed so that we never mistakenly match or override the (keycode, keysym) pair. (int, str) vs (str, int)
This creates some "interesting" data structure mangling in places that only expect the latter (ie: older clients - but no actual regression bugs so far).
r20422 allows us to use this new modifier mapping map format, which should help AlrGr work in more cases, r20423 handles it better server side.

Related: r20421 tries to workaround a GTK3 bug which looks awfully similar to Crash when accessing the "string" attribute of GdkEventKey on 64bit Windows which we recorded in #1818.

Ubuntu beta packages are available: [https://xpra.org/beta].
In theory, all of these fixes could be backported - not sure I am brave enough..

@Matteo Ipri: does that work for you?

@totaam
Copy link
Collaborator Author

totaam commented Sep 25, 2018

2018-09-25 18:48:01: maxmylyn commented


Tested this with Firefox (61) and Chrome (69) in Fedora 28 and Windows 8.1 with a trunk r20530 Fedora 28 server, and everything appears to be right about what I expect.

I don't have access to any non-US keyboards, but I do have multiple layouts installed and the keys show up right about where they should be.

Closing.

@totaam totaam closed this as completed Sep 25, 2018
@totaam
Copy link
Collaborator Author

totaam commented Feb 14, 2020

Keyboard support much improved in #2574.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant