xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 5 years ago

Closed 5 years ago

Last modified 12 months ago

#1484 closed defect (fixed)

HTML5 client. Keyboard layout on-fly change

Reported by: Denis01 Owned by: Denis01
Priority: major Milestone:
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Follow up from #1487:
Somebody already told about this function but seems not declared ticket (at least I have not found, correct me if I am wrong).
So it would perfect if that function appears in the following versions.

Change History (6)

comment:1 Changed 5 years ago by Denis01

Version html5-2.0.1-2.r15507

system reacts on keyboard change (in tray or by hot-keys) but after the switch EN->RU cyrrilic symbols are not treated properly - nothing appears and remote application considers the symbols typied as key-combinations cnrt-F, cntr-C, etc
To restore it is needed to re-login with preferred language to use and not to change keyboard on-fly to avoid the problem appear

comment:2 Changed 5 years ago by Denis01

Type: enhancementdefect

comment:3 Changed 5 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Denis01

"en" keys (latin keys really) are still mapped on a "ru" keyboard layout, which is why switching from "ru" to "en" works.
But many "ru" keys do not exist on an "en" keyboard layout, and so they cannot be mapped.

Sadly, there is no reliable way of detecting the current locale used for keyboard input. See "locale" in KeyboardEvent (only supported by IE)
And even the more convoluted layout detection code we have does not apply when the user changes the layout: if I call setxkbmap us on my client system, all the HTTP request headers and all the browser attributes still have my preferred locale first ("en_GB").
r15510 adds code to re-detect the keyboard layout whenever one of those properties changes, but it doesn't fire with chrome or Firefox. (not tested IE)

So I was starting to think that this could not be fixed without requiring user interaction and adding a language menu to the html5 toolbar. (planned in #1471)
But then it occurred to me that we can guess which keyboard layout is actually needed based on the keyname (ie: "Thai_thothan" requires a "Thai" or "th" keyboard layout), so r15511 does that.
With this change, the HTML5 client will request the server to switch to a new keyboard layout when it sees keys it knows belongs to a specific layout ("Greek", "Thai", "Cyrillic", "Hebrew", etc)


  • there may be a slight delay as the change is aynchronous
  • we rate limit those changes to prevent server DOS
  • this will not switch back to the original layout when the user starts typing in "latin" again because we don't keep track of all the layouts we have used, only the current one
  • there's bound to be some corner cases, but this is likely to be as good as it is going to get given Javascript's API limitations

comment:4 Changed 5 years ago by Denis01

Resolution: fixed
Status: newclosed

had some fun with VPS provider on OS version :-) Now ready for tests

version 2.1-r15507 64-bit
Linux CentOS Linux 7.3.1611

it seems that everything works properly. En->Ru, Ru->En

comment:5 Changed 3 years ago by Antoine Martin

See also #2154

comment:6 Changed 12 months ago by migration script

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

Note: See TracTickets for help on using tickets.