Non-US keyboard layouts about novnc HOT 95 CLOSED

i would do both:
a. use key sequences to guess the keyboard
b. let them select

from novnc.

I'm having problems here with a german keyboard layout and at least the backslash key. Instead of a backslash noVNC sends a left bracket [.

The codes send with different Browsers:

• IE9: FFE3, FFE9, 005B down and 005B, FFE3, FFE9 up
• FF4: FFE3, FFE9, 005B, 005C down and 005C, FFE3 up
• Opera 11.11: FFE3, FFE9, 00DF, 005C down and 005C, FFE3 up

Unfortunately i have not the permissions to reopen this issue.

from novnc.

Chome 48 has implemented KeyBoardEvent.code which represents the physical key that generated the event independently of the keyboard layout.

It's also supported no Firefox 38+ and Opera 35+ (source).

from novnc.

Is anyone working actively to solve this issue? If not, I can try to implement the QEMU extension again. It might take a while (I worked in this one year ago ...) but now I believe it is feasible.

from novnc.

I believe the code is ready to be tested and reviewed. Please feel free to test it with your keyboard layouts, using latest Chrome/Firefox/Opera and connecting to a QEMU-compatible vnc server such as a VM from virt-manager.

https://github.com/danielhb/noVNC

from novnc.

For anyone interested, I've backported the my implementation of the QEMU extension that fixes this bug to the latest noVNC release, 0.5.1. The code can be fetched here:

https://github.com/danielhb/noVNC/tree/0.5.1_qemu_extension

Same conditions apply (recent Firefox/Chrome/Opera browsers, must connect to a QEMU VNC server).

from novnc.

Article by Daniel with further defails and background: https://www.ibm.com/developerworks/library/wa-support-multiple-keyboard-layouts-in-web-based-vnc-apps-trs/index.html

from novnc.

That's a great idea. Except I have no experience in that area and no easy way to validate it even if I did implement it. Any examples of good implementations? Or even better would be working patches :-)

from novnc.

http://guacamole.svn.sourceforge.net/viewvc/guacamole/trunk/web/javascript/

from novnc.

A while ago Colin Dean of xvpsource.org sent me a patch that attempted to add Non-US keyboard layout support.

Here is the original patch: https://gist.github.com/763752

Here is the patch with some modifications I made to it: https://gist.github.com/2e7f20be852a4527df63

The patch switches from using keydown and keyup events to using the keypress event to get the charCode value which is then mapped through a Unicode table to get the keysym value.

Unfortunately, after playing around with it I discovered a couple of issues that prevent it from being a solution for noVNC:

• Using the keypress event means that we can't distinguish and send separate keydown and keyup events. This means the key events sent to the server don't truely reflect what the user is doing on the client side.
• To receive the keypress event we have to allow the keydown event to propagate normally. If we stop the keydown event, the keypress event will never fire. However, stopping the event at keypress time is too late to prevent certain browser hot-key actions from firing. For example, if the user presses Ctrl-A and we don't stop the keydown event from propagating, then everything on the page is selected. This is an annoyance, but there are other cases that are worse such as Ctrl-W.

The implication is that in order to do the right thing we will have to determine the right keysym from the keyCode of the keydown event and not rely on the charCode of the keypress event.

Most of Colin's patch probably won't be used (although the u2x11 script probably will be), but it was invaluable to me to figure out what really needs to be done.

from novnc.

Some useful links:

• quirksmode writeup of keystroke issues: http://www.quirksmode.org/js/keys.html
• quirksmode page on events in general: http://www.quirksmode.org/dom/w3c_events.html
• more cross-browser info mentioned by that quirksmode page: http://www.hallvord.com/opera/keyevents.htm
• detecting shift/ctrl/alt keys: http://www.cross-browser.com/x/examples/shift_mode.php
• more on detecting modifier keys: http://www.javascripter.net/faq/ctrl_alt.htm
• still more on modifiers with specific info for older browsers: http://www.webreference.com/js/column11/modifierkeys.html

It sounds like the altKey, shiftKey and ctrlKey properties of the key events may be fairly cross-browser (in the browser versions we care about) which is very good if true.

from novnc.

Also, I added tests/keyboard.html which prints keyboard event data (keyCode, charCode, which, altKey, shiftKey, ctrlKey, translated keysym).

from novnc.

One thought I've had for how to generate keyboard layout data is that we may be able to create a page that generates fake keyboard events to determine what the keycode+modifiers to charCode data is (i.e. generate keydown event and trap the keypress event),

It's possible this is fast enough (and reliable enough) in all browsers we need to support that we might be able to do this on page load in noVNC. But at least we could have a publicly accessible page where people could generate and then submit their layout data.

But at the very least we might be able to use the technique with just a few key events to binary search for the keyboard layout that the user is using. Assuming there is no better way to determine that (I haven't searched in detail for how JavaScript can determine keyboard layout).

from novnc.

if the keyboard layout could be configurable, it could resolve many problems...
for non-us keyboard, it can be very hard to type

from novnc.

I tried to integrate the patch from Colin Dean, as noVNC is mostly no usuable for typing text. The git is https://github.com/moobyfr/noVNC
Fell free to comment if it works for you. I tested on french layout, and is ok for normal keys + modifiers. The only issue is AltGr key

from novnc.

moobyfr, the change in your fork is not actually functional. You have only added the x11.js file without using it. Perhaps you forget to push the rest of the changes.

Also, as I mentioned in the 3rd comment there are two major issues with Colin's approach: the keydown and keyup messages are no longer detected and sent separately, unintended browser events are no longer disabled (e.g. Ctrl-W will close the browser tab rather than sending a Ctrl-W).

I am very willing to accept additional keyboard layouts, however the layout must key off off keydown and keyup events and not key off of the keypress event as with Colin's patch. If you would like to develop a French layout that keys off of keydown/keyup then I would gladly pull it into the project.

from novnc.

I've spent some time to look for the way to go. The keydown/keyup is the way to intercept ~all keys. But there is something bad in the management with javascript for key events. keyCode contain a key reference for a qwerty keyboard, and the real char is in CharCode.
So to be realistic, noVNC should transmit keyCode to say which key was pressed.
The basic idea is, as you said , and I tried, is to map keyCode to other values depending to the key pressed. But layout are more than just keys moved: on a azerty keyboard, two differents key can return the same value, and there is no way to distinguish them only with keydown/keyup: Example, the "-" and "_" on a qwerty is on the same key, and differentied with the shift modifier. the keyCode value is 189. On a azerty layout, these two symbols are on two differents keys. the keyCode returned by the browser for each key is 189!
So only with the keyCode (and modifiers), it's not possible to make a table to manage differents layout.
That's why the charCode has to be used.
I've looked in guacamole code, the same is made: trap keydown to know that a key has been pressed, and use keypress, if needed, to get the real charCode to send.

Javascript doesn't give us all the power :/

from novnc.

noVNC has to use keyCode and not charCode for two reasons: first so that we can send the keydown and keyup separately (for some keys on some layouts we may have to work around this due to keyCode limitations as you describe), but the second and bigger issue is that using charCode requires the key event to propagate/bubble which means that certain key sequences are seen by the browser and cause unintended behavior such as tab, space, enter, Ctrl-W, Ctrl-Tab, etc. If Guacamole is using charCode then they have this problem.

Here is a concrete example of the second problem. On most browsers, Ctrl-Minus will shrink the font size and Ctrl-Plus will increase the font size. In order to prevent this from happening in noVNC (and just send the Ctrl-Minus/Plus on to the server), we stop the keyDown event and don't allow it to propagate. However, another effect of stopping the event is that there is no keyPress event generated. I don't know of any way to both generate a keyPress event and prevent bubbling into default browser actions.

That is really terrible that on certain keyboard layouts multiple keys generate the same keyCode in Javascript.

If anybody has a sudden stroke of brilliance about how to solve the keyboard layout problems without bad side-effects, I'm all ears. In the meantime, we may just have to provide a way (button) for the user to send a '_' character when using an azerty keyboard.

Do we know of other keys that have the same overlapping key layout abomination?

from novnc.

I may ask this question on stackoverflow.

from novnc.

I've asked the question on stackoverflow here: http://stackoverflow.com/questions/5306132/translate-javascript-keycode-into-charcode-for-non-u-s-keyboard-layout-i-e-aze

from novnc.

more informations: 3x 2 keys have same keyCode: ";" and ":" are differents keys, and "!" and shift + "&"
Some more fun: 6 other keys send a 0 value for keyCode: (in the qwerty mapping for having a better idea of the mapping) : the key 2 7 9 0 and the two keys right of "p" and "m"
And the best: the key 4 (" ' " on a azerty ) only show keypress events, and no up/down!!

I have another proposition: add an option to noVNC to use the up/down event only for qwerty users, or the keypress for international users with less functionalities...

from novnc.

moobyfr, thanks for your work on this. It's a really messy area and I just use a standard U.S. keyboard layout so it's difficult for me to determine exactly where the issues lie.

It looks like it's going to have to be something like a fallback for non-US layouts. Although, again, the biggest issue is not getting the mapping correct, the biggest problem is preventing unintended default browser behaviors. So it's likely that keypress will only be used for non-US keys when no modifier key (other than shift) is pressed at the same time. When a modifier (other than shift) is pressed we still can't use keypress on any key layout.

from novnc.

Okay, it's a huge challenge but I think I've made some forward progress here:

c96f900

In summary:

• I've added a keyPress handler and I report a key down for normal (safe) key combinations when the keyPress event happens.
• For special (browser action) key combinations I report the key down in the keyDown event and suppress further action.
• In order to report the key up properly I add a key event to a list in keyDown, give that element a keysym value in keyPress, and then pop that item off the list and use the keysym value during keyUp to report the key up.
• I've also incorporated Colin Deans character code to keysym lookup table for values above 255.

This isn't a 100% solution since key combinations that cause browser events (tab, enter, backspace, Ctrl-, Alt-, etc) are not translated before being sent, but for normal typing we should be able to get keyboard mapping correct now.

I'm going to leave the bug open for a while since I have not been able to test this much on alternate keyboards so I'm sure there are issues, but I think the framework is in place to be able to solve most of the issues.

from novnc.

Also, see this commit and the comments with it: https://github.com/moobyfr/noVNC/commit/c0615b935cc1e0e5cc9be222405185bbf829294a

from novnc.

I'm closing this issue. I don't have a great way of testing this myself. I can switch keyboard layouts and poke around a bit and things seem to be working fairly well, but I'm not a real user of non-US layouts so I'm relying on community feedback. If anybody listening uses non-US keyboards and is having issues, please re-open. Thanks.

from novnc.

@tenchman, I've reopened the bug. I can't seem to replicate your problem on Linux (Ubuntu Maverick) with Chrome 12, firefox 4.0.1, or Opera 11.11. I'll have to try with browsers under Windows at some point (I assume that is where you are seeing this?)

Just to make sure, is this the keyboard layout you are using? http://en.wikipedia.org/wiki/Keyboard_layout#Germany_and_Austria_.28but_not_Switzerland.29
And are you pressing Alt_Gr and then the key two over from the backspace?

from novnc.

the current version of novnc can't handle correctly AltGr key. In USA, right ctrl + alt can do the same, but these keys don't exist on european keyboards

from novnc.

@moobyfr: hmm, interesting. I only have a US keyboard and have been switching layouts to test. Can you see what key code AltGr generates on a real French keyboard? @tenchman, if you press and release just AltGr on a German keyboard, what does noVNC report?

from novnc.

Yes, this is exactly the keyboard i'm referring to and yes, it's a Windows issue. Same keyboard on Linux with FF, Opera, Chrome works like a charm. The same key sends 0x5c under Linux and 0x5b when pressed under Windows. (Note the funny sequence for FF4 under Windows in my previous comment)

This is what noVNC reports when pressing only AltGr

IE9

onKeyDown kC: 17 cC:undefined w:undefined
keyPress down 1, keysym: 65507 (key: 17, which: undefined)
onKeyDown kC: 18 cC:undefined w:undefined
keyPress down 1, keysym: 65513 (key: 18, which: undefined)
onKeyUp kC: 17 cC:undefined w:undefined
keyPress down 1, keysym: 65507 (key: 17, which: undefined)
onKeyUp kC: 18 cC:undefined w:undefined
keyPress down 1, keysym: 65513 (key: 18, which: undefined)

Firefox and Opera

onKeyDown kC: 17 cC:undefined w:undefined
keyPress down 1, keysym: 65507 (key: 17, which: undefined)
onKeyDown kC: 18 cC:undefined w:undefined
keyPress down 1, keysym: 65513 (key: 18, which: undefined)
onKeyUp kC: 17 cC:undefined w:undefined
keyPress down 1, keysym: 65507 (key: 17, which: undefined)

from novnc.

I used :http://kanaka.github.com/noVNC/noVNC/tests/keyboard.html
on firefox and chrome, there are events but all 0 ....

2: Dn: key:0 char:0 which:0 id:undefined ksym:0 alt:false shift:false ctrl:false
3: Pr: key:0 char:0 which:0 id:undefined ksym:0 alt:false shift:false ctrl:false
4: Up: key:0 char:0 which:0 id:undefined ksym:0 alt:false shift:false ctrl:false

On chrome there is no KeyPress Even notified

from novnc.

I was not precise in latest comment: in chrome there is at least the keyDown and keyUp event, with 0 as value.
AltGr is a modifier, so just relying on up/down is enough, I made a patch and a pull request to integrate it .

from novnc.

Hmm, any chance to get this keymap-thing resolved? We need non-us-layouts, really :-)

from novnc.

@neufeind, I would LOVE to resolve this. However, as I noted, I don't use an international layout and the issue is tricky. The current solution is better that it was originally, but there are still problems (for example with the AltGr key). If somebody steps up and provides a really good fix then they will earn eternal glory (well, at least a mention in the credits).

I think the ultimate solution may be to exactly characterize the problem and report bugs to the various browser vendors because I think there is no good solution without the browser providing more accurate/precise information during key events. I don't have the time, or knowledge/access to international keyboard layouts so this will need to be driven by somebody else (although I will certainly give assistance to whoever steps up).

from novnc.

while I was looking for the bugreport about altGr key in Chromium, I found the following bug report in guacamole, which handle the keys through javascript:

http://guac-dev.org/trac/ticket/136?cversion=0&cnum_hist=9#comment:11

The comment 11 explain the processing of keydown before keypress, and these keypress are ignored. An workaround has been implemented too in theirs client.

BTW, firefox 16a1 now report a real value (225) for the AltGr Key! (keyIdentifier is still 0)

from novnc.

Interesting technique. noVNC does try and use keyPress rather than keyDown when it can but using a 0 timeout would allow it to be more aggressive about that. Anybody want to take a crack at it. Especially someone with an internal layout that can reproduce the problem?

from novnc.

I made some more tests and looked the code again: the code is already using this method keyPress preferred over keyDown. In fact it is working, but it depend of the vnc server :/

The key "à" has keysym 224 and AltGr "à" gives me the char @ which has keysym 64
-> I press "AltGr" Key and the Key "à", it gives me the char @ (keysym 64)

• If I use vnc4server I get the input @ on my xterm.
• If I use the buildin VNC server in qemu, I get the char "à"

I had a look in the vnc code from qemu: when a keysym comes in, it's converted in a name which is converted to a scancode.

To find out the scancode the way is keysym 64 -> "at" (@) . The "at" is looked into the fr keymap, wich says :

agrave 0x0b
0 0x0b shift
at 0x0b altgr

As no modifier was sent, the scancode for agrave is used.

from novnc.

I'm also having a lot of trouble with this. I'll try to put in some debugging time tomorrow to find which characters aren't working. I'm using a azerty belgian keyboard.

Weird thing is that when I try to setup ubuntu with the belgian keyboard settings and type "azerty" it comes uit "qwerty". When I use US keyboard settings it comes out 'azerty", don't know if this is a problem with noVNC. But I'll try to find out.

from novnc.

in the case of a belgian layout, there should be no problem with at least with
the main ascii characters accessible with only one keypress

Emmanuel

IUT R.Schuman
Université de Strasbourg

from novnc.

My mistake, seems to be a problem with the vnc server.

from novnc.

Pressing and then releasing AltGr (using Danish keyboard layout, but I'd assume it's the same for any layout where AltGr exists), Firefox (16.0.2, Windows) reports the following:

onKeyPress down, keysym: 65507 (onKeyDown key: 17, which: 17)
onKeyPress down, keysym: 65513 (onKeyDown key: 18, which: 18)
onKeyPress up, keysym: 65507 (onKeyPress key: 17, which: 17)

which, if I'm reading your code correctly, means that it registers keypresses on ctrl and alt, and then releasing only ctrl.
The behavior we're seeing is pretty much that: it's as if the alt key sticks.

Other browsers release both keys properly when AltGr is released.

Fun stuff. I must say, after looking at input.js, I'm impressed that you've got it working as well as you have. This is the only keyboard issue we've come across so far.

from novnc.

Are you using a Firefox on Windows ?
In Linux version, the AltGr key has it's own code.
In windows it seems that AltGr is handled by simulating alt and ctrl :/

On Tue, Nov 6, 2012 at 10:01 AM, jalfd [email protected] wrote:

Pressing and then releasing AltGr (using Danish keyboard layout, but I'd
assume it's the same for any layout where AltGr exists), Firefox (16.0.2)
reports the following:

onKeyPress down, keysym: 65507 (onKeyDown key: 17, which: 17)
onKeyPress down, keysym: 65513 (onKeyDown key: 18, which: 18)
onKeyPress up, keysym: 65507 (onKeyPress key: 17, which: 17)

which, if I'm reading your code correctly, means that it registers
keypresses on ctrl and alt, and then releasing only ctrl.
The behavior we're seeing is pretty much that: it's as if the alt key
sticks.

Other browsers release both keys properly when AltGr is released.

Fun stuff. I must say, after looking at input.js, I'm impressed that
you've got it working as well as you have. This is the only keyboard issue
we've come across so far.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-10103412.

from novnc.

I have a noVNC that can handle emulated AltGr key events on any browsers including Firefox for windows in my sandbox.
I can upload it here if you want.

from novnc.

@moobyfr: yes, sorry, this is on Windows. I should've mentinoed that. (And just edited my comment)

from novnc.

@takaha BTW, I commented on your pull request with some suggested changes before I merge it in.

@jalfd seems like a possible bug in Firefox. If you have time to create a simple test case, you might consider doing that and filing a bug with Mozilla on this. Make sure to report back here if you do so (test case and bug link). Of course, in creating a simple test case you might also learn something noVNC could be doing to work around it.

from novnc.

I uploaded a snapshot of my sandbox:
#212

This supports non-us keyboard layouts. Japanese and European keyboards will work with noVNC on all popular browsers.
I hope non-us keyboard users will give me feedback.

Thanks.

from novnc.

Yeah, it's definitely a bug in Firefox, and I filed a bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=809410 -- no news on it yet, however.

However, I played around a bit more, and found that there are a few hints that might be used to detect the situation. The location field is actually set, so the precise key sequence reported by Firefox is "left CTRL down, right ALT down, left CTRL up". That can at least help distinguish from the more common case where you actually press left CTRL and ALT. Further, the timestamp is set to the exact same value for the CTRL and ALT keypresses (which would never happen if they were pressed individually) Anyway, I've been a bit stretched for time lately, so that's all I have for now. :) I'll try to play around with it some more when I have a bit of time :)

from novnc.

From my latest patches with noVNC, I think this is still an issue... I am basically using an English (US international with dead keys) keyboard and seems that the accents are not being correctly handled. Is there any update on this? I might have some ideas but I would like to see what is the current status in case there was any updates on the last 1.5 year.

from novnc.

There has been a lot of progress. Keyboard handling has been completely rewritten, and I'm not currently aware of any bugs that aren't due to browser limitations at the moment.

What specifically doesn't work for you?
Which browser and OS are you using?

from novnc.

I am using noVNC to access a guest running on top of QEMU. QEMU is the VNC server in this case. I have a Fedora 20 machine running Gnome 3 and Firefox 31. My machine is configured to use "English (US international with dead keys)" keyboard. When I connect to the VNC session through noVNC, dead keys doesn't work, which means I cannot type things like 'ê' or 'ç'. I heard some people having similar issues with French keyboard layouts (although I don't have the details). I tried to use Chinese input method as well without much success.

from novnc.

I am using noVNC to connect to my proxmox VMs. I cannot use keys like /, {, }, and | as they get interpreted as other keys. The machine I'm connecting to is using the USA layout and is running Debian 6. The machine I'm using noVNC on is using Windows 8.1 with swiss german layout.

from novnc.

What keys do /, {, }, etc register as? There's a lot of interesting logic that goes into how noVNC interprets keypresses (see https://github.com/kanaka/noVNC/wiki/KeyEvents for more information). If you open up "input.html", what key presses are displayed?

cc @jalfd

from novnc.

@ruffy91 It is probably the AltGr key issue again as reported at #406. You can work around it in noVNC but it seems to be mainly an issue of the keyboard conversion of the VM.

from novnc.

@laggarcia Sorry, I didn't notice your response until now. it sounds like you're running into issue #350. Currently, Firefox on Linux is borked when it comes to dead keys. (Firefox bug 1077411)

@ruffy91 as DirectXMan12 said, we need a bit more information before we can look into this. Try launching input.html in your browser and see how the relevant keys are processed, and let us know the result.

from novnc.

To use the input.html page, do I need to do anything special befhorehand? I'm seeing (in Chrome and Firefox on Fedora 20) a page with two boxes, but the Canvas input box won't accept input.

from novnc.

Huh, looks like someone broke it!

You're not supposed to do anything special, just load the page, and press various keys on the keyboard. But yeah, I get javascript errors when I try to load it now.
I'll try to take a look one of the next couple of days.

from novnc.

Thanks. That seems to work now. I'm having trouble reproducing the issues I'm hearing about without a non-US keyboard, so I'll have to come back to this when I can be of more help.

from novnc.

I now have a German keyboard and can get back to this.

Right now using noVNC and a Ubuntu guest I´m seeing a popup when I press ö, ä, or ß. The popup says, "No map for [key]."

Using the input.html, ö gives
1: raw key event keydown (key: 0, char: 0, which: 0)
2: raw key event keypress (key: 0, char: 246, which: 246)
3: RFB keypress down keysym: 246 key name: 246
4: raw key event keyup (key: 0, char: 0, which: 0)
5: RFB keypress up keysym: 246 key name: 246

and I have no idea if that's correct or not. :)

Also, nothing shows up on the canvas, so, that probably needs to be fixed as well.

from novnc.

@clnperez : the canvas is just there to act as a focus for the input events

When you get a popup, do you mean the VNC target gives you a popup, or the browser gives you a popup?

from novnc.

@DirectXMan12 The VNC target gives the popup.

from novnc.

I am experiencing these issues using a Brazilian ABNT2 keyboard (it is similar to the en_us layout but with the cedilla 'ç' key and a couple changes in the accent keys). When trying to get accents such as 'ã', 'à', 'á' or 'â' (which are the combination of ~. `, ' and ^ keys plus 'a') nothing is displayed in Chrome (latest) and Firefox (36.0). The cedilla key, however, works.

Input.html output shows that for all the above dead keys noVNC provides no mapping:

0: Display initialized
1: raw key event keyup (key: 219, char: 0, which: 219)
2: raw key event keyup (key: 222, char: 0, which: 222)
3: raw key event keyup (key: 219, char: 0, which: 219)
4: raw key event keyup (key: 222, char: 0, which: 222)

Only raw key events are displayed.

This is the mapping for the working cedilla key:

19: raw key event keydown (key: 186, char: 0, which: 186)
20: raw key event keypress (key: 231, char: 231, which: 231)
21: RFB keypress down keysym: 231 key name: 231
22: raw key event keyup (key: 186, char: 0, which: 186)
23: RFB keypress up keysym: 231 key name: 231

I am trying to solve the problem by looking in keyboard.js but so far no luck. Any tips?

from novnc.

@clnperez that output looks correct. noVNC is sending an ö to the VNC server. I suspect the problem is on the server side then.

@danielhb which OS are you using?

There is a known big in Firefox on Linux (#350) that prevents dead keys from working.

The reason ç works for you, but other accented characters don't is that on a Brazilian keyboard, ç is a separate key, while stuff like ã are composed using a dead key.

0: Display initialized
1: raw key event keyup (key: 219, char: 0, which: 219)
2: raw key event keyup (key: 222, char: 0, which: 222)
3: raw key event keyup (key: 219, char: 0, which: 219)
4: raw key event keyup (key: 222, char: 0, which: 222)

Looks like you're only getting keyup events from the browser. If you never get keydown/keypress events, there's not much noVNC can do. Do you get this output in both Firefox and Chrome? That seems weird.

from novnc.

OS: Fedora 21 x86_64

Just did the test again with Chrome (Version 41.0.2272.118 (64-bit) ) and Firefox (37.0.1). This time I pressed the same dead key (key " ' ") multiple times:

Results in Chrome:

0: Display initialized
1: raw key event keyup (key: 219, char: 0, which: 219)
2: raw key event keydown (key: 229, char: 0, which: 229)
3: raw key event keyup (key: 219, char: 0, which: 219)
4: raw key event keyup (key: 219, char: 0, which: 219)
5: raw key event keydown (key: 229, char: 0, which: 229)
6: raw key event keyup (key: 219, char: 0, which: 219)
7: raw key event keyup (key: 219, char: 0, which: 219)
8: raw key event keydown (key: 229, char: 0, which: 229)
9: raw key event keyup (key: 219, char: 0, which: 219)

In Chrome I can say that I can only get a keydown after the second time I press the same dead key. If I press 2 dead keys alternately (" ' " and " ~ " for example) I get only keyup events:

0: Display initialized
1: raw key event keyup (key: 219, char: 0, which: 219)
2: raw key event keyup (key: 222, char: 0, which: 222)
3: raw key event keyup (key: 219, char: 0, which: 219)
4: raw key event keyup (key: 222, char: 0, which: 222)
5: raw key event keyup (key: 219, char: 0, which: 219)
6: raw key event keyup (key: 222, char: 0, which: 222)
7: raw key event keyup (key: 219, char: 0, which: 219)
8: raw key event keyup (key: 222, char: 0, which: 222)
9: raw key event keyup (key: 219, char: 0, which: 219)
10: raw key event keyup (key: 222, char: 0, which: 222)

Results in Firefox (pressed the key 3 times):

0: Display initialized
1: raw key event keydown (key: 0, char: 0, which: 0)
2: raw key event keypress (key: 0, char: 0, which: 0)
3: raw key event keyup (key: 0, char: 0, which: 0)
4: raw key event keydown (key: 0, char: 0, which: 0)
5: raw key event keypress (key: 0, char: 0, which: 0)
6: raw key event keyup (key: 0, char: 0, which: 0)
7: raw key event keydown (key: 0, char: 0, which: 0)
8: raw key event keypress (key: 0, char: 0, which: 0)
9: raw key event keyup (key: 0, char: 0, which: 0)

from novnc.

Let me report the things that are getting in my way at this moment:

• browser differences. Each browser treats keyboard events in a different manner. Firefox doesn't provide any keyCode for the dead keys. Chrome doesn't provide all the events when pressing a dead key. At this moment it will be very hard to fix this bug in a cross-browser way

• the attribute keyCode is deprecated according to the Moziilla docs (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent). We're now supposed to use KeyboardEvent.key attribute instead, but, at this moment, this attribute is not fully implemented by any browser. Firefox 37 has partial support for it but without dead keys yet. There is a bug opened to track the implementation by Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=680830). In my opinion noVNC will need to review the keyboard.js implementation when this attribute became available, not using keyCode at any point or only if the browser has no other alternative.

• With the current keyCode implementation in Chrome I didn't find a way to implement accentuation. You can simulate this easily even with a en_us keyboard. Using the default en_us layout (without dead keys), pressing the " " (grave) key will print the character immediately. Changing the layout to en_us with dead keys, the char will not be printed in the first key stroke. We need a second key press to print the character because the system was waiting to see if the dead key will compose a new char (" à " for example). At this moment, we can't distinguish between the " " char and the dead key " ` ". The new attribute KeyboardEvent.key would report the value "DEAD_GRAVE" for the latter.

• I have tried to find a way to detect the current keyboard layout in Javascript but, as far as I can tell, only IE has support for that (haven't tested it)

• I've also looked for a way to disable the browser's keyboard shortcuts altogether instead of doing all the filtering noVNC does. Not much luck in that too.

I hope these information can help anyone trying to solve this bug. With the future implementations of the new 'key' attribute I hope we can fix it.

from novnc.

Firefox doesn't provide any keyCode for the dead keys. Chrome doesn't provide all the events when pressing a dead key. At this moment it will be very hard to fix this bug in a cross-browser way

Yep. However, events for dead keys aren't strictly necessary. What matters is that the key following the dead key has a valid char/charCode property. After all, the entire point in a dead key is that it's dead. Pressing it doesn't generate a character that we can send to the VNC server. Instead, we just ignore it and wait and see what character is generated by the next keypress. (But of course, that depends on the browser telling us what that key is at least)

Also note that keyCode isn't really a very useful property. It tells us some implementation-defined name for the physical key, but not which character the keypress generated. The only way in which noVNC could translate that into a character would be if the user (1) explicitly told us which keyboard layout to assume and (2) we had tables describing every possible keyboard layout in detail. And even then we would have to implement some fairly complicated logic for combining and composing characters, knowing exactly which character would be generated if this key is pressed after that dead key, and this other modifier key is held down. That's not practical. It would be insanely complicated. So what we currently do instead is this:

• there is a set of keys that are "fixed" and always have the same meaning (enter, space, tab, caps lock, ctrl, alt, backspace and so on). For those, the keyCode property actually tells us what we need to do, and we can act on that.
• for all graphical characters, the keyCode is useless, and we have to wait for an event that specifies either the char or charCode property. (Those are usually available on keypress events). These properties give us a Unicode code point value for the generated character, and we can trivially map that to a keysym identifier, which the RFB protocol expects.

The main thing we use keyCode for is really to match keydown, keypress and keyup events together. (keydown gives us a keyCode. When we see a keypress with that keyCode, we can look at its charCode to see which character to send to the server. When we see a keyup we can take its keyCode and use that to look up in an internal state table to see which character has been sent to the server. And then we can send a KeyUp event on that character)

So if the browser doesn't give us any events with char or charCode set, then it's pretty much game over. There's not much we can do (other than fixing the bug in the browser)

From the output you listed, it looks like neither Chrome and Firefox on Linux give us a charCode when you repeatedly press dead keys. That sucks.

In my opinion noVNC will need to review the keyboard.js implementation when this attribute became available, not using keyCode at any point or only if the browser has no other alternative.

Agreed. When I overhauled the keyboard handling, KeyboardEvent.key wasn't really useful, but as it gets better supported by browsers, we'll eventually need to switch over to that. But it sounds like that wouldn't solve the dead keys issue.

With the current keyCode implementation in Chrome I didn't find a way to implement accentuation

What is supposed to happen is this:

• you press the dead key `
• you get a keydown event specifying the keycode (followed by a keyup)
• you press another key, say, e
• you get a keydown specifying the keycode
• you get a keypress specifying the charcode 0xe8 (the code point for è)
• you get a keyup event.

That is, the actual composition of dead key + non-dead key happens by the browser, and it tells us that the resulting character is a è. So we don't need to do anything when a dead key is pressed. We just wait for the browser to tell us which character to send to the server. The browser, not noVNC, has to handle accentuation.

Now if only they'd do that correctly. :/

from novnc.

I agree that we have browser issues here, but even leaving it aside, I think there are some improvements we can do in order to make noVNC more reliable, specially when dealing with a VNC server that is run by QEMU to access a guest console.

If I am following the discussion here, Javascript code receives a unicode value from the browser, which noVNC translates to the value used by the RFB protocol, which states: "The key itself is specified using the "keysym" values defined by the X Window System, even if the client or server is not running the X Window System."

Using X Window System keysym values is known to cause issues to QEMU VNC server, mainly because if you are not running X Windows System on the server side, an X Windows System keysym is lots of times useless (and actually maps to the wrong key, depending on the application running on the VNC server). Because of that, Anthony Liguori proposed an extension to the RFB protocol which is understood by the QEMU VNC server and that enables it to deal directly with the key codes generated by the Linux kernel. I think one possible way to fix the keyboard issues we are having is to implement this in noVNC. Yes, that would need an additional translation from unicode value or X11 keysym value to Linux key code, but I think it would solve some of the issues (from what I read here, it seems that other issues are dependant on browser bugs...)

from novnc.

I've worked with this issue for the last weeks and I've had some progress.

Chromium (= Google Chrome upstream) had an issue that was fixed recently about dead keys events ( https://code.google.com/p/chromium/issues/detail?id=478643 ). After some struggle compiling Chromium in a Fedora 21 (the recommended OS to build it is Ubuntu) I managed to get a build running and tested the dead keys there. I can say that, as far as dead keys are concerned in an en_us keyboard and a pt_br abnt2 keyboard, noVNC + Chromium works when connecting to Tiger VNC sever. After this discovery, all the work I've been doing in this issue is considering Chromium. If you're coming to this bug with a dead key problem in noVNC, I strongly recommend to give Chromium a shot.

As said by laggarcia in the previous message, I want noVNC to work properly in QEMU-VNC server. To make that happen, I'm working in implementing QEMU-VNC extensions into noVNC. Actually only one of them, the QEMU Extended Key Event Message. Basically this is the same message noVNC already sent in key press but with an extra field, the X11 keycode that generated the keysym. This conversion is being done by using a hashmap which was generated by parsing the mapping from gtk-vnc. This extension will only be enabled if the server sends a RFB Framebuffer Update saying that it supports it. Otherwise the default noVNC behavior takes place.

The current status: it works, but the dead keys are still a problem. After further debugging and investigation, I believe that this is a matter of which key events the client is sending to the server. noVNC does not send the dead keys to the server because, by design, dead keys does not send keypress events, only keydown (http://javascript.info/tutorial/keyboard-events). QEMU-VNC server requires the dead key to be sent as well - the combination is handled by the server. This is what I am looking at right now. I am trying to find a way to (1) send all the dead key events to the server and (2) make sure that this new workflow does not interfere with the "non-QEMU" workflow. (1) is presenting to be trickier than I've expected, but I believe that (2) shouldn't be much of a problem.

As always, any comments or tips are welcome.

from novnc.

My conclusion after working in this bug for the last weeks is that the fix is not possible ATM. I'll post here how far I went and what are the current limitations that prevented the fix.

I've implemented the QEMU VNC extension into noVNC and it worked remarkably well for the en_us and pt_br keyboards. But it won't work for german and any other keyboard layout that is not QWERTY. The reason is that the QEMU VNC extension dictates that we must pass the XT scancode (= physical location of the key pressed. The 'Q' key in a QWERTY is the second key of the third row) to the VNC server. This information can be retrieved by applications that can grab the keyboard events directly, but in noVNC we are stuck by the info that the browser provides.

Firefox and Chrome does not provide such information - we can see the IE keycode, which is the same value for all the layouts, but there is no information about the current user layout. Thus, testing the german keyboard with the QEMU VNC extension, the Z and Y keys are switched, among others. The reason why it works with en_us and pt_br layouts is that the IE keycode the browsers provide matches the XT scancode for en_us. There is a W3C draft that describes extensions to the keyboard support for the browsers (https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm), but this has no ETA unfortunately.

TL;DR to fully implement the feature we need more keyboard support from the browser side.

from novnc.

I'm using OS X on a MacBook where the builtin keyboard has a German layout, but I use an external keyboard with US layout. The OS X system language is English, the input language is set to U.S. and navigator.languages is ["en-US", "en"].

I use noVNC with Proxmox / QEMU in Google Chrome, connecting to a machine with keyboard set to us.iso.kdb: United States of America ISO-8859-1

However, pressing y prints z and / prints 7.
That seems like a German keymap, though I can't figure out why that would be used.

I tested pressing y:

0: Display initialized
1: Touch device detected
2: raw key event keydown (key: 89, char: 0, which: 89)
3: raw key event keypress (key: 121, char: 121, which: 121)
4: RFB keypress down keysym: 121 key name: 121
5: raw key event keyup (key: 89, char: 0, which: 89)
6: RFB keypress  up  keysym: 121 key name: 121

Looking at keysym.js, 89 (0x0059) is Y and 121 (0x0079) is y.

That seems to be matched correctly.

Interestingly, using the German keyboard with input language set to German works when the VM keyboard is also set to German. However it does not work with everything set to US. I've also tried setting some things to German and some to US, but it only gets messed up.

tl;dr: everything is set to US but it seems to use a German keymap.

Am I doing anything wrong?

from novnc.

Actually, everything is (mostly) working when the OS X input language is set to German while actually using the US keyboard and VM keyboard set to US.
That doesn't seem to be right, though.

from novnc.

Same strange thing here (using noVNC in Xen Orchestra, see https://github.com/vatesfr/xo-web/ )

• "en" layout in my system with VM "EN" keyboard: working great!
• "en" layout in my system with VM "FR" keyboard: working great! (writing in French)

But if my own system layout is in "fr" (French), all is inverted, despite using "FR" or "EN" (or whatever) in the VM keyboard.

from novnc.

This one is pretty long. Is there any way or patch which works at least partly for a local installation / branch?

from novnc.

@danielhb I don't believe anyone is working on this at the moment. That would be awesome!

from novnc.

@samhed alright, I'll pick it up from where I left one year ago, rebase with the current master and see how far we can advance this time.

I'll keep this bug updated with any developments

from novnc.

Great! Tell me if there is something I can do to help!

from novnc.

Update: I am having good progress with this attempt. The core logic is ready and it's already functional. I've tested it with FR (azerty and dvorak) and German (classic) keyboards with success. The tests were made in a Fedora 23 host, Google Chrome 49, noVNC connecting to VMs created by virt-manager.

At this moment I am fixing some issues with Num Lock handling. After that I'll do a clean up (the code is a mess right now, swarmed with console.log() calls) and push it to a noVNC fork so everyone can give it a shot.

It's worth mentioning that this is a QEMU extension implementation and will fix the issue if, and only if, the VNC server supports this extension. I stood as far away as I could of the logic that implements the non-QEMU case. Also, any browser that does not implement the KeyboardEvent.code (see http://caniuse.com/#feat=keyboardevent-code ) will not be supported by this implementation (in short, it will work on latest Chrome, Firefox and Opera). I am considering adding a browser type/version check before enabling the QEMU extension.

Daniel

from novnc.

+1 to @DirectXMan12 - I tried it with german keyboard, typing altGr+l which suppose to print "@", does nothing.

from novnc.

@benbracha @DirectXMan12 Have you tested with @danielhb patches referenced above? They might fix your issue.

from novnc.

@laggarcia - yes, I tried @danielhb version

from novnc.

@benbracha can you specify which German layout are you using? Because I just tested here with my version, with the layout I believe it's the German default for Gnome and the "@" works fine. However it's AltGr+Q that gives "@", not AltGr+I.

from novnc.

@benbracha don't know if this is exactly the layout you're using, but just tried it here with German - Austria (Macintosh) and it worked too (with AltGr + L ).

What browser are you using? The code will not activate in any browser but latest stable Firefox, Chrome and Opera

from novnc.

I just installed a German keyboard on my mac (see its layout below) - and locally it prints "@" using alt+l, but I don't see this when using your noVNC version.

Am I missing something?

from novnc.

What VNC server are you trying to connect to? Are you trying to connect to xvnc, tigervnc, QEMU vnc ...?

Supposing that you're connecting to a QEMU compatible VNC server, using Firefox >= 44 or Chrome >= 48 or Opera >= 36 and mapping the exact same keyboard layout inside the VM, it should work.

I've tested it a lot with Linux and Windows 10 but haven't tried Apple. I'll fire it up an old Mac Air here and see if there's something I didn't predict.

from novnc.

Thanks. Sorry for not being verbose with the details. So:
I'm connecting to a QEMU vnc, Chrome latest version.
Probably what I'm missing is... "mapping the exact same keyboard layout inside the VM" - what do you mean by that?

(I'm used to work with guacamole, and at least as I understand - the keyboard layout of the VM is not important, as eventually the actual characters (charCode that are raised from keypressed JS events) are sent to the remote VM. I may miss something here though..
I tried your solution as I cannot figure out how to solve "dead-keys" issues which are not working with gacamole, and hoped you solved it).

from novnc.

(I'm used to work with guacamole, and at least as I understand - the
keyboard layout of the VM is not important, as eventually the actual
characters (charCode that are raised from keypressed JS events) are
sent to the remote VM. I may miss something here though..

Keyboard layout is not important only when you are using the same
graphical user interface on both sides (client and server), e.g. X11,
which is what VNC protocol uses by default. charCode raised from
keypressed JS event is way high level and a number of transformations
happen between your key press, the operating system getting it and
passing it to the JS engine. If you are connecting to a VM, the best way
to deal with this is to send the actually keycode received by the
operating system to the remote server (that's what QEMU provides through
a VNC extension because on the VNC server end, you actually have a full
operating system running, not only a graphical user interface). But if
you do that you need to set the keyboard layout on the VM properly, as
you are not sending charCodes to the VM, you are sending actually
keycodes (which are much lower level and need to be mapped to a keyboard
layout to be meaningful).

I tried your solution as I cannot figure out how to solve "dead-keys"
issues which are not working with gacamole, and hoped you solved it).

Yeah, that's one of the issues you might see when passing charCodes to
the VM instead of actual low level keycodes.

from novnc.

@laggarcia Thanks for the explanation! Just to be clear, when you are saying:

Keyboard layout is not important only when you are using the same
graphical user interface on both sides (client and server)

What do you mean by "client and server"? My set up has:

• A client (my local machine, that use noVNC via browser) - Mac OS / Chrome
• A server (the VM that runs QEMU and the noVNC proxy) - Ubuntu 14.04
• A "client VM" (the VM that runs on top QEMU) - Ubuntu 14.04

In this setup - should I set the the "client VM" keyboard layout to German as well (like it is set on my Mac)?

from novnc.

@benbracha I see where you're coming from. I'll explain why as succinct as I can, because this is a long story/topic and @laggarcia already explained a bit.

The implementation you're talking about is the regular VNC implementation of key events. You send the key symbol (keysym) to the remote server, the remote server shows it and that's it. This is trivial for VNC clients that have direct access to the keyboard map of the OS and can tell, for example, that AltGr+L does nothing in an English layout but it produces the keysym "@" in yours.

QEMU VNC servers, on the other hand, can't be treated as regular VNC servers. QEMU is a hardware emulator which emulates everything, including the keyboard. In this regular VNC implementation, when connecting to the QEMU server, sending a "@" keysym would cause QEMU to transform it back to the actual key strokes that generated it. In en_us layout, it would be Shift+2. But you haven't pressed shift+2, you pressed AltGr+L. But there's no way QEMU knows your layout beforehand. That leads to a lot of problems, as you might have noticed.

Then it comes the QEMU extension, the work I've done in noVNC. It does not rely on sending keysyms, but the actual physical key pressed. It's a different code from the regular noVNC keyboard handler. In your case for example, AltGr+L will be sent as 'key of row 6 column 5' + 'key of row 4 column 10'. This is what the QEMU VNC server receives and sends to the VM. So, in order to get the "@" in the VM, the VM must match your own keyboard layout. Supposing that you didn't change the VM keyboard, AltGr+L in a en_us layout gives you no symbol.

So, in order to properly make the keyboard work in your case, the VM layout must match the "source" layout.

from novnc.

"In this setup - should I set the the "client VM" keyboard layout to German as well (like it is set on my Mac)?"

Exactly. Not only "German" but the exact same layout you're using. In Ubuntu15 it's called "German-Austria-Macintosh"

from novnc.

Thanks @danielhb - this really sheds more light on this, and improve my understanding.
I tried the set up the keyboard on the "client VM" as you suggested, using "sudo dpkg-reconfigure keyboard-configuration", and still couldn't get it work.

I you think this is not related to this issue, I would be happy to take this offline with you (email), as it can help me a lot.

I did notice this thing:

Even if I don't change my "client VM" keyboard and leave it as is (english), when I switch my mac between EN and DE keyboards and send "y" - the "client VM" behaves as expected - types "y" or "z" accordingly. According to your explanation, this shouldn't be possible unless I'll change the "client VM" keyboard to DE.. Maybe I'm missing something more basic with my setup?
For example - I assume your changes relates only the the server-side of noVNC, as I still use regular noVNC client from http://kanaka.github.io/noVNC/noVNC/vnc.html. Should I use your vnc.html?

from novnc.

On 04/13/2016 11:20 AM, Ben Bracha wrote:

Thanks @danielhb https://github.com/danielhb - this really sheds
more light on this, and improve my understanding.
I tried the set up the keyboard on the "client VM" as you suggested,
using "sudo dpkg-reconfigure keyboard-configuration", and still
couldn't get it work.

I don't know what dpkg-reconfigure keyboard-configuration does. I would
rather set the keyboard manually. In Ubuntu 15 it's under 'Keyboard' ->
'Input sources'. Then select language and layout type. You can see a
drawing of the keyboard layout to ensure that it matches yours. You're
using Ubuntu 14 but I am guessing it is similar.

I did notice this thing:

Even if I don't change my "client VM" keyboard and leave it as is
(english), when I switch my mac between EN and DE keyboards and send
"y" - the "client VM" behaves as expected - types "y" or "z"
accordingly. According to your explanation, this shouldn't be possible
unless I'll change the "client VM" keyboard to DE.. Maybe I'm missing
something more basic with my setup?

The reason is that the QEMU VNC extension isn't enabled. Otherwise
pressing the 'Y' key (row 3 column 7 key) would always result in the "y"
symbol in the VM set with English layout. In fact, the extension doesn't
care about the client keyboard layout. It's the VM layout that counts.

Another thing that really counts is the browser version. You said that
you're using latest Chrome. Which version is that in your case? You can
see the version by issuing chrome://version in the address bar.

For example - I assume your changes relates only the the server-side
of noVNC, as I still use regular noVNC client from
http://kanaka.github.io/noVNC/noVNC/vnc.html. Should I use your vnc.html?

It's actually the opposite. My changes are on the client side, in the
javascript files.

If you want to be sure that you're running the right code, just use the
code from https://github.com/danielhb/noVNC . It's the noVNC master code

• my patches and you use it the same way.

I you think this is not related to this issue, I would be happy to
take this offline with you (email), as it can help me a lot.

I am interested to see your case working or at least figured because
there's always a chance that I've missed some detail, perhaps something
specific of Mac.

Feel free to email me at [email protected] if you want to take the
discussion offline.

from novnc.

Thanks, now I see it work (I didn't use your noVNC client side, only the server side, as I thought your changes were on the server side..).
After setting the "client VM" to match my exact Mac layout (BTW - dpkg-reconfigure keyboard-configuration just let you do that in the Ubuntu terminal, as I don't have a desktop there..), I see the "@" sent when using AltGr+l.
Nice!

It seems like dead-keys are working as well.. at least I tried the AltGr+n that generates a "~" and AltGr+u that generates quotes, although I couldn't get them to add "accent"
For example: doing AltGr+n+n should do: "ñ" But I got ~n (it may be that Ubuntu terminal can't print it?)

from novnc.

Nice to see it worked!

Ubuntu terminal doesn't print all the available characters. Try opening
'gedit' and test it there

On 04/13/2016 11:57 AM, Ben Bracha wrote:

Thanks, now I see it work (I didn't use your noVNC client side, only
the server side, as I thought your changes were on the server side..).
After setting the "client VM" to match my exact Mac layout (BTW -
dpkg-reconfigure keyboard-configuration just let you do that in the
Ubuntu terminal, as I don't have a desktop there..), I see the "@"
sent when using AltGr+l.
Nice!

It seems like dead-keys are working as well.. at least I tried the
AltGr+n that generates a "~" and AltGr+u that generates quotes,
although I couldn't get them to add "accent"
For example: doing AltGr+n+n should do: "ñ" But I got ~n (it may be
that Ubuntu terminal can't print it?)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#21 (comment)

from novnc.

@danielhb so in libvirt, with your patch, there should be no keymap set, correct?

For example:

<graphics type='vnc' listen='0.0.0.0' port='-1' autoport='yes'/>

instead of

<graphics type='vnc' listen='0.0.0.0' port='-1' autoport='yes' keymap='fr-ca'/>

See also: https://www.redhat.com/archives/libvir-list/2009-May/msg00234.html

from novnc.

@dkelson yes, you're right. No keymap set in libvirt or QEMU, following the recommendation in the link you sent:

"Our recommendation is to never set the '-k' /keymap option at all these
days. Recent QEMU / KVM and GTK-VNC releases support a VNC extension for
sending raw keycodes, instead of localized keysyms. Thus is best to leave
off the keymap in the config, and just configure it inside the guest OS."

from novnc.

@danielhb : it's work fine for me ! I port your patched version of noVNC in my webvirtcloud fork to try it : https://github.com/brenard/webvirtcloud/tree/html5_console

I make my tests with Chromium Version 49.0.2623.108 Built on 8.3, on multiple libvirt/KVM VNC instances without specific keymap configure in libvirt XML configuration, with french keymap configure in VM and french keyboard (azerty).

from novnc.

I'm glad it worked @brenard ! Thanks for testing it!

from novnc.