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