en input in a ru browser #62
Comments
|
Is The solution to this is often to configure the server side virtual keyboard as |
But my client's keyboard layout is
When I press When I press
I think in the Docker file, I don't configure the server at all. When browser language is English, there seem to be no problem with any of the layouts. |
Xpra doesn't know that.
Changing the keyboard layout is an expensive operation, definitely not something that can be done fast enough to be done before handling a key event.
That looks quite odd. It doesn't find the keycode when pressing ( |
|
I have the same issue: RU/UA layout works if I select "Russia" or "Ukraine" in HTML5 advanced options and also works if Android on-screen keyboard switches to Russian or Ukrainian, but switching back to English is impossible. I think I will refactor simple-keyboard usage to implement dynamic layout switching and also add full-width layout and floating layout for tablets. |
|
@basilgello could you test diff --git a/html5/js/Client.js b/html5/js/Client.js
index f1aca91..368583b 100644
--- a/html5/js/Client.js
+++ b/html5/js/Client.js
@@ -119,8 +119,7 @@ XpraClient.prototype.init_state = function(container) {
this.cipher_out_caps = null;
// detect locale change:
this.browser_language = Utilities.getFirstBrowserLanguage();
- this.browser_language_change_embargo_time = 0;
- this.key_layout = null;
+ this.key_layout = this._get_keyboard_layout();
this.last_keycode_pressed = 0;
// mouse
this.last_button_event = [-1, false, -1, -1];
@@ -655,44 +654,19 @@ XpraClient.prototype._check_browser_language = function(key_layout) {
* This function may send the new detected keyboard layout.
* (ignoring the keyboard_layout preference)
*/
- const now = Utilities.monotonicTime();
- if (now<this.browser_language_change_embargo_time) {
+ if (this.key_layout==key_layout)
return;
+
+ this.clog("input language changed from", this.key_layout, "to", key_layout);
+
+ var new_layout = key_layout;
+ if (new_layout==null) {
+ var kb_layout = this._get_keyboard_layout();
+ new_layout = this.key_layout == kb_layout ? "us" : kb_layout;
}
- let new_layout;
- if (key_layout) {
- new_layout = key_layout;
- }
- else {
- //we may have used a different layout for a specific key,
- //and now this new key doesn't need it anymore,
- //so we may want to switch back to the original layout:
- const l = Utilities.getFirstBrowserLanguage();
- if (l && this.browser_language != l) {
- //if the browser language has changed,
- //this takes precedence over the configuration
- this.clog("browser language changed from", this.browser_language, "to", l);
- this.browser_language = l;
- new_layout = Utilities.getKeyboardLayout();
- }
- else {
- //this will honour the setting supplied by the user on the connect page
- //or default to Utilities.getKeyboardLayout()
- new_layout = this._get_keyboard_layout() || "us";
- }
- }
- if (new_layout!=null && this.key_layout!=new_layout) {
- this.key_layout = new_layout;
- this.clog("keyboard layout changed from", this.key_layout, "to", key_layout);
- this.send(["layout-changed", new_layout, ""]);
- //changing the language too quickly can cause problems server side,
- //wait a bit before checking again:
- this.browser_language_change_embargo_time = now + 1000;
- }
- else {
- //check again after 100ms minimum
- this.browser_language_change_embargo_time = now + 100;
- }
+
+ this.key_layout = key_layout;
+ this.send(["layout-changed", new_layout, ""]);
};
|
|
I did something similar already and it works. However, to solve this issue completely, I see two options:
1. Get a list of keymaps on server and if keystroke does not belong to a "special language" (RU/UA, from that array), default to first "non-special" language (en/us, or whatever language user has, like "fr", "es" etc).
This will work for Latin characters but it is still the question how to choose a proper keymap for diacritics etc? I suppose we can map Unicode natiinal glyph ranges to keymaps (it is easy and can be automated) and force the "keymap_change" event from that list.
2. Another option is to use an approach similar to xdotool or xtype.py: implement so-called "direct mode" within Xpra that wraps the unicode character into a virtual keymap consisting only that character, change the keymap via XKB and emulate keypress via XTest.
This approach works well even with Indian / Korean / Thai glyphs but it might be slower than current approach.
What do you think?
|
|
The changes that this would revert are from #65. (see also #66) As I said before, changing the keymap is expensive and this is something that should be avoided if at all possible. It will block the UI thread for a little while and it will trigger keymap-changed events in all the applications listening for it. So, I think option 1 is safer, but perhaps option 2 should be used when option 1 fails to locate the keysym? |
|
I tried patch from #62 (comment) , and I does not work for me. I am not sure that it same bug about RU/EN layouts, but I reproduced "sticking on EN or RU layout" by connecting from two browsers (after second shared connection, layout switching is broken).
2min demo of this with this patch applied → https://vimeo.com/653322622 So, any workaround appreciated… Or should I create another bug? |
Supporting multiple concurrent connections and expecting layout switching to work is not supported. |
|
Perhaps #142 can help with this? |
Here we go again.
Server
Dockerfile:run as
docker run --rm --name=xpra_debug --net=host --mount type=tmpfs,destination=/run/user/0/xpra -v/etc/machine-id:/etc/machine-id $(docker build -q .) xpra start --daemon=no --bind-tcp=127.0.0.1:8080 --html=on --start=xtermOn the client, lets use Chrome(ium), and set the first language to Russian (
chrome://settings/languages)Connect to the Xpra server (
chromium-browser 127.0.0.1:8080), it should say smth likeWhen I connect to the server from the current HTML5 client, I see the virtual keyboard, which helps reproducing the issue.
If I click on
1on the virtual keyboard, I see1printed in thexterm. If I click on a letter, say,q, there is nothing printed inxterm, but I seein the Chrome devtools JS console in both cases.
Typing cyrillic letters works fine. If the first browser language is English, then typing both en and ru letters seems to work fine.
If you help me with emitting keyboard events from the devtools console, I'll try to provide reproducer for pressing cyrillic letters. I've tried dipatching
keydownKeyboardEvents todocument.bodyordocument.querySelector("#pasteboard"), but it doesn't seem to work.The text was updated successfully, but these errors were encountered: