Dead keys do not work

[samhed]

No dead keys work in Firefox on Linux. By dead keys I mean ~"^`'
Tested on CentOS 6 and Fedora 18 with both Firefox 26 and 27.

It does work in other browsers such as Google Chrome and there is no problem on Windows (tested with Win8.1).

[jalfd]

What exactly happens when they're pressed? They're just ignored?

[samhed]

Yep, nothing happens

Edit:
when using tests/input.html I get this whenever I press a dead key:

raw key event keyup (key: 0, char: 0, which: 0)

[jalfd]

I'll have a closer look at this tomorrow, but it looks like this might be tricky to do anything about.

Firefox simply isn't giving us any useful information on dead key presses. Of the properties key, char, keyCode, charCode and which, the only one which is set to anything other than 0 (or undefined) is key, which is set to the constant DeadAcute when you press ´. We could add a big mapping table for these key names (which, as far as I can tell, are Firefox specific), but this doesn't solve the important problem, because composing characters with dead keys doesn't seem to work either. And adding such a mapping table would not solve that.

If I press ´ followed by e, I would expect to get a keypress event for the é character.
But all the browser gives us is a keypress where key === MozPrintableKey and charCode === 101 (and 101 is the Unicode code point for e... Without any accents).

Unless the browser has come up with some other way to access this information, this looks like a lost cause. It is possible that we are supposed to use the new-fangled input event for some of this, but I haven't looked closely at when/how/if it is emitted and what information it carries.

W3C also mentions compositionstart, compositionupdate and compositionend events which seem to be intended for exactly this, but as far as I can tell, Firefox doesn't use them.

I'll dig a bit more in this, but so far, it's not encouraging.

[kanaka]

@jalfd noVNC is probably one of the heaviest users of this sort functionality. We should definitely file bugs with the vendors when we run into this sort of thing. They are probably willing and happy to fix it (although maybe not always prompt), but they may just not know about it or may not realize that it impacts a real-world webapp. And name drop noVNC when you do (and refer to tests/input.html so that there is an easy way for them to test).

[DirectXMan12]

Is this still a problem? Can we close this?

[jalfd]

This can still be reproduced in the most recent Firefox version.
I've filed bug 1077411 against Firefox.

Until they fix it, there's not much we can do. (Short of hardcoding mappings from combinations of dead keys + character to the resulting composite or accented character, which would be really nasty.)

[hex-m]

As a workaround, you can disable dead keys on your client. Doesn't help in a multi-user environment but works for me. (Firefox on Xenial and noVNC on Proxmox 4.1)

[danielhb]

Doesn't #21 fix this bug too?

[CendioOssman]

Unfortunately no, because:

a) The browser might not be able to provide physical keys in all cases
b) The server might not support this extension
c) Sending physical keys is not a silver bullet, but rather a different trade-off. As such some users may prefer the symbol based approach.

[danielhb]

I don't think (b) is a problem nowadays - recent VNC servers have been supporting this extension for 5+ years, giving the original QEMU VNC extension was developed in 2010 or so.

But I agree with (a) and (c). I think this bug will have to wait for the solution of the Firefox bug mentioned a few comments above.

[CendioOssman]

I don't believe any of the RealVNC derived servers supports this, i.e. TigerVNC, TightVNC, TurboVNC, or the new proprietary RealVNC. So I'd say b) is very much an issue. Is there any server besides QEMU and libvncserver that supports it?

[danielhb]

You're right. Disregard my comment about (b).

[laggarcia]

I don't believe any of the RealVNC derived servers supports this, i.e. TigerVNC, TightVNC, TurboVNC, or the new proprietary RealVNC. So I'd say b) is very much an issue. Is there any server besides QEMU and libvncserver that supports it?

Servers based on gtk-vnc library supports this extension.

[CendioOssman]

This is broken in Chrome as well, and likely in all browsers:

https://bugs.chromium.org/p/chromium/issues/detail?id=1135952
https://bugs.chromium.org/p/chromium/issues/detail?id=586568

[CendioOssman]

Also reported to the standard folks:

whatwg/dom#900

[sergiomb2]

Doesn't #21 fix this bug too?

I think it not , I can't write an é (é) and all others accented keys in a novnc session novnc-1.3.0

[sergiomb2]

but for me the question is how I can type one accentuated characters ? , I found one workaround which is type the accentuated character in clipboard of novnc . Question can we map characters with on combination of keys ? characters like é ã ó ?

[sergiomb2]

I found for alt-gr + 7 , 8 ,9 or 0 is another problem , is just when I use x11vnc instead vnc-server

and repeting the question how you , type characters that need one dead key ?

[sergiomb2]

have we anyway to have composed keys like ~ + a ?

BTW I found x11vnc with -nomodtweak fix the altgr problem mention in my previous comment

[kwibus]

To summarize the problem, how I understand it so far:
NoVNC does not send keysym for dead keys.
This is because:

• Novnc uses keydown, keyup events to detect keyboard events.
• Those events give event.key == Dead. But little indication which dead key.

I see 3 Possible Solution directions.

Solution 1, guess dead key from event.code etz.

This has the problem this depends on they keyboard layout. which is unknown to the browser.
But:

• You only have to do this for Dead Keys, not all keys
• there lots of overlap between keyboard layouts, dead keys list
  • when the overlap, it works for both
  • If the conflict you can't resolve it

This is not a perfect solution. But you can get it to work for most used keyboard layouts, with deadkeys.
Which might be better the Nothing.

I have a working POC that works for us international keyboard layout with:

• XK_dead_grave: `
• XK_dead_diaeresis: "
• XK_dead_acute: ´
• XK_dead_circumflex: ^
• XK_dead_tilde: ~

atcomputing/noVNC@master...atcomputing:noVNC:#350-solution-1

Solution 2. use compositionupdate from uievent

In theory this would give you more accurate information about which deadkey is pressed in compositionupdate event.data

But:

• don`t know if this will work for canvas, instead of input element
• Losts of browers only implement compositionupdate fro IME input. not for Dead keys for normal keys.
  This is at least the case for all windows browser i tested. and Firefox on Linux.
• Still have to find out how to map event.data to right symbol.

Solution 3. ignore dead keys until it results in a real key.

keypress (deprecated) and input, events give you the result of keypress with dead keys.
So if you type: " + e It will send ë on second keypress.
So novnc should ignore first keypress, and use result input.event for the second.

But:

• don't know yet how to get input events for noVNC
• keypress would work. but is officially deprecated
• But this will reliable work for all keyboard layouts.

Wich solution do you think would work best for noVNC?
I can try to implement a pull request for it?

[sergiomb2]

Hi, many thanks , on solution 1, is to apply on server ?

[kwibus]

@sergiomb2 the code fore solution 1 it bit of prove of concept.

• It makes deadkeys used in us-international work in Linux, and probably mac (not yet tested),
• other keyboard layout support i still have to look into. if you have preference for a specicif layout, I could try that as example for further improvements
• I noticed it print some dead keys twice on windows, I think this is easy to fix.

But you could try it as for your noVNC server

[sergiomb2]

With Firefox I got the console logs of the events and I managed to put all my dead keys working perfectly .
but in Google chrome or electron don't work so well

[kwibus]

@sergiomb2 might be better to continue this conversation here: #1907

[CendioOssman]

I see 3 Possible Solution directions.

There is also the fourth option, using the QEMU raw keyboard event extension. It is supported by various servers.

It would move the keyboard layout handling to the server instead of the client. And dead keys work fine under that model, as far as I know.

[kwibus]

There is also the fourth option, using the QEMU raw keyboard event extension. It is supported by various servers.

True, if I understand the code correctly, this will send keysym, and scancode instead of scancode.
keysym is still unknown.

I did my testing mostly with TigerVNC, there it tried to use QEMU extension, but it did not work.
I assumed this was because keysym was 0,
But i had not really checked if Scancode was set wrong.

I have to look into that, It might help.