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.
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?
@afarr: mostly a FYI I think, feel free to close.
@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.
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
Oops, sorry about that - not sure how I ever managed to get that going, should be fixed in r12383.
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)
Replying to antoine:
Finally I have been able to test this - I can confirm this works in my setup, too.
with an r12690 trunk server and a Win8.1 Firefox/Chrome? client:
Maybe it's just me?
@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'
@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.
@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.
@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.
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.
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.
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.
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
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
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.....
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.
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
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1147