Xpra: Ticket #1147: html5 client does not detect keyboard layout with chrome or firefox

As reported here: http://lists.devloop.org.uk/pipermail/shifter-users/2016-March/001492.html, the keyboard layout detection code browser/xpra/tags/v0.16.x/src/html5/include/xpra_client.js works with IE but not chrome or Firefox.



Wed, 16 Mar 2016 04:50:43 GMT - Antoine Martin: owner, status, description changed


Tue, 22 Mar 2016 09:21:40 GMT - mayerm: cc set


Thu, 24 Mar 2016 14:19:30 GMT - Antoine Martin: owner, status changed

The keyboard layout is not exposed to browsers. What works for IE is not the layout but the locale, which happens to usually be the same, but there is no equivalent for the other browsers at all. (see http://stackoverflow.com/a/27861755/428751)

So r12210 allows the user to select the desired layout on the connect screen, and it should default to the locale if we detect one (with IE) or to the language of the browser (others).

@mayerm: does this work for you?


Tue, 29 Mar 2016 16:32:14 GMT - Antoine Martin: owner, milestone changed

@afarr: mostly a FYI I think, feel free to close.


Tue, 29 Mar 2016 22:45:49 GMT - mayerm:

@antoine: This definitely looks like it would work for me. I have been exploring ways to solve the issue and hacked a similar solution myself but yours is much more flexible, generic and maintainable. Thanks so much for taking care of this.


Wed, 13 Apr 2016 22:49:49 GMT - alas: owner changed

Hmm, turns out this was one that I was interested in (testing with html5 client I sometimes like to use an ñ...) enough to try it out a bit.

Unfortunately, against a 0.17.0 r12380 fedora 23 server, I find the /connect.html page is failing to connect the client.

Tested with Chrome, Opera, & Safari ... got the same console error on all:

Uncaught SyntaxError: Unexpected token :
connect.html:148 Uncaught ReferenceError: doConnect is not definedonclick @ connect.html:148

Thu, 14 Apr 2016 04:05:35 GMT - Antoine Martin: owner changed

Oops, sorry about that - not sure how I ever managed to get that going, should be fixed in r12383.


Thu, 14 Apr 2016 22:18:29 GMT - alas:

With a 0.17.0 r12385 server, I can successfully connect through the /connect.html page with Chrome, but I don't seem to be able to input any other keyboard-mapped inputs (tried to use the Israel option after installing Hebrew fonts on fedora 23 server ... was able to input Hebrew characters I can't read with python clients, but unable to do so with either OSX Chrome or Windows Chrome, even when changing the keyboard input settings client side before trying to connect using the Israel button).

With Safari & Opera, I wasn't even able to connect through the /connect.html page (in case we care) ... got the following in dev tools console log output from both.

[Error] ReferenceError: Can't find variable: doConnect
	onclick (connect.html:148)

Mon, 18 Apr 2016 17:15:05 GMT - mayerm:

Replying to antoine:

Finally I have been able to test this - I can confirm this works in my setup, too.


Thu, 26 May 2016 21:07:31 GMT - J. Max Mena:

with an r12690 trunk server and a Win8.1 Firefox/Chrome? client:

Maybe it's just me?


Fri, 03 Jun 2016 08:56:51 GMT - Antoine Martin: owner changed

@maxmylyn: how are you changing the layout? I go back to the connect page, change to a new layout and hit connect then the server shows the corresponding line in the log:

setting keyboard layout to 'XYZ'

Fri, 03 Jun 2016 15:54:39 GMT - J. Max Mena:

@antoine:

I use Win + Space to switch keyboard layouts. I disable the Control + Shift shortcut because I hit that all the time when highlighting blocks of text.


Sat, 04 Jun 2016 03:47:43 GMT - Antoine Martin:

@maxmylyn: you are changing your client's keyboard layout on the fly using a keyboard shortcut (this must be some Linux X11 desktop of some sort), this cannot be detected by the html5 client. We detect the browser's locale (and only for the browsers that expose this information) and derive from it our best guess of what the keyboard layout is likely to be, which is also why the connect dialog lets you override it. AFAIK, the browser locale cannot be changed without re-installing a different build of your browser and re-connecting to the session.

If you want the ability to switch keyboard layouts on the fly within the html5 client, we would need to add to the UI the ability to select secondary layout(s) and pass the key combination that we want to use for layout switching to the server. (which we would also be unable to detect in html) This would belong in a different ticket.


Wed, 22 Jun 2016 20:37:30 GMT - J. Max Mena: owner changed

@antoine:

With an r12890 server, I can connect with the Germany layout, but the y and z are not swapped like they should be. I'm using an ENG-US keyboard with that layout selected in Windows, but it doesn't appear to be overriding.

I'm also seeing what afarr sees in comment:6 - using the hebrew layout with Israel selected still gives me the regular old ENG-US layout on the server.

The logs do indicate that it set the keyboard layout to 'il' or 'de', but appears to have no effect.


Thu, 23 Jun 2016 03:13:48 GMT - Antoine Martin: status changed

I can connect with the Germany layout


I assume that you're using the drop down menu on the connect page?


I'm using an ENG-US keyboard with that layout selected in Windows


As per previous comments, this makes no difference whatsoever. We have no way of knowing what layout is set in the OS from the browser's javascript API. The only thing we can take a guess from is the browser locale, ie: "Firefox in German".


The logs do indicate that it set the keyboard layout to 'il' or 'de', but appears to have no effect.


I'll take a look.


Wed, 10 Aug 2016 02:40:42 GMT - Antoine Martin: owner, status changed

I am a bit confused now: "appears to have no effect", what effect did you expect to see? Selecting "il" or "de" layout will only allow you to enter the special keys found on those layouts, ie: "ß". It will not change the keys sent by the browser. If you are "using an ENG-US keyboard with that layout selected in Windows", then the keys will be sent using this layout.

Short answer: I think this is working as expected. The drop-down menu only allows you to override the detection (which is based on the browser locale), so that you can match the layout actually selected in your OS. It does not and cannot change the keys we receive from the OS.


Wed, 10 Aug 2016 16:17:05 GMT - J. Max Mena: status changed; resolution set

It will not change the keys sent by the browser. If you are "using an ENG-US keyboard with that layout selected in Windows", then the keys will be sent using this layout.


Short answer: I think this is working as expected. The drop-down menu only allows you to override the detection (which is based on the browser locale), so that you can match the layout actually selected in your OS. It does not and cannot change the keys we receive from the OS.


Okay, then you're correct here and it's working as expected. I was under the impression that it would receive keys as if they were coming from the different layout (as in swapping 'y' and 'z' on the 'de' layout). Since that is not the case, then this is working fine. In addition, it fixes the issue for the original person who reported it. Closing.


Sun, 02 Apr 2017 09:36:39 GMT - Denis01: priority, status changed; resolution deleted

Hello, can't switch the layout into Russian.

Client - HTML5, Browser Chrome (and on IE as well)
Server Centos
System Locale: LANG=ru_RU.UTF-8
VC Keymap: ruwin_alt_sh-UTF-8
X11 Layout: ru

Manually set up in drop down menu on the connect page in Advance menu - Russia Command string in browser ....port=10000&encoding=auto&'''keyboard_layout=ru'''&submit=true&clipboard=true

Error log -d keyboard:
.....
reenable_keymap_changes(())
modifier_map({})={'control': 4, 'mod1': 8, 'mod2': 16, 'mod3': 32, 'mod4': 4, 'mod5':128, 'lock': 2, 'num': 0, 'hyper': 0, 'meta': 0, 'shift': 1, 'alt': 0, 'super': 0, 'scroll': 0}
compute_modifier_keynames: keycodes_for_modifier_keynames{'ISO_Level3_Shift': [124],'Mode_switch': [8], 'Meta_L': [64, 156], 'Control_R': [109], 'Super_R': [116], 'Alt_R': [113], 'Hyper_L':], 'Caps_Lock': [66], 'Hyper_R': [132], 'Alt_L': [64, 125], 'Num_Lock': [77], 'Super_L': [115, 127], 'Shift_R':[62], 'Meta_R': [113], 'Control_L': [37], 'Shift_L': [50]}
keys_changed() updated keyboard config=KeyboardConfig( / None)
client 1: got hello: server version 2.0 accepted our connection
client 1: startup complete

Sun, 02 Apr 2017 09:52:29 GMT - Antoine Martin: owner, priority, status changed

1) please see comment:16, this only sets the server's keyboard layout - what keys your browsers sends is up to the browser 2) this is not a blocker bug


Sun, 02 Apr 2017 10:24:16 GMT - Denis01: attachment set


Sun, 02 Apr 2017 10:26:21 GMT - Denis01:

Hello Antoine, 1) apologize for the type of the bug 2) checked in Chrome, Windows, etc (3 images is the attached file)- Cyrillic everywhere but still typing in Latin symbols.....


Sun, 02 Apr 2017 10:27:46 GMT - Antoine Martin:

Like I said, what your browser sends is up to your browser, so I am likely to close this ticket again. Please do NOT attach docx files to this tracker, attach images as images.


Sun, 02 Apr 2017 12:17:51 GMT - Denis01:

Antoine, could you please give an advice how this browser feature with languages might be changed/fixed.... As I completely deleted the EN keyboard layout from PC... and even had difficulties with the local Windows logon ....had to change password into special symbols at MS site.... So PC could not speak English at all - only Russian... in Putty, textpad, any browser - no possibility to tape in Latin. And still in xpra typing the same way. Could it be somehow some settings at server side? Thank you in advance! Denis


Mon, 03 Apr 2017 06:20:45 GMT - Denis01: status changed; resolution set


Sat, 23 Jan 2021 05:16:16 GMT - migration script:

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