Dead key symbols not included in KeyboardEvent

[CendioOssman]

The current standard states that dead keys should set key to the value "Dead" no matter which dead key is pressed. This unfortunately makes dead keys completely undetectable by applications such as noVNC which need to know the proper symbol to send to the remote end:

novnc/noVNC#350

The standard currently refers to using composition events, but they are not a replacement as they only give you the current composed state, not the symbol that was just included to update the state.

Composition events also only work on input fields, not other keyboard event targets such as a canvas. So even if they did contain the proper information, they would still not be a valid replacement.

(moved here from whatwg/dom#900)

[garykac]

The standard currently refers to using composition events, but they are not a replacement as they only give you the current composed state, not the symbol that was just included to update the state.

The data attribute of the compositionupdate event should indicate the dead key. As shown in this example: https://www.w3.org/TR/uievents/#example-a785f64b

Composition events also only work on input fields, not other keyboard event targets such as a canvas. So even if they did contain the proper information, they would still not be a valid replacement.

You should be able to get these events if you give the canvas a tabindex attribute.

I realize this isn't ideal for your case, but I hope that this is enough to unblock you.

[CendioOssman]

The data attribute of the compositionupdate event should indicate the dead key. As shown in this example: https://www.w3.org/TR/uievents/#example-a785f64b

Thank you for the reference.

Unfortunately, the browsers don't seem to follow that example. Is the behaviour more explicitly defined somewhere? All three major engines send U+00A8 in the data field instead of the appropriate U+0308. And this is on Linux, where detecting dead characters is trivial. I assume it's even worse on Windows and macOS.

And even if the browsers did it correctly, I'm afraid it looks like it would fall apart if more than one dead key is used after each other, as data shows the current state and not the last pressed key.

The behaviour of key for the keydown and keyup events also varies.

The example states that it should be the composited symbol. Is this clearly specified anywhere except this example? Because we really don't want that for our use case. We want the symbol only affected by modifiers, nothing else. So we'd need an alternative to key if the browsers started implementing this bit correctly.

For Firefox, it varies, and it sometimes sends the uncomposited symbols, and sometimes the composited.

Chrome either sends the uncomposited symbol, or the special "Process" value, which I doubt is correct.

WebKit sends either sends the uncomposited symbol, or "Unidentified".

You should be able to get these events if you give the canvas a tabindex attribute.

Unfortunately not. I'm guessing the browsers equate composition with IME, and a full-blown IME will not work properly with a non-text element. So they likely disable the entire thing.

The composition events are also unreliable, even for a text element. On Linux, which composition events I get depends on the desktop environment I have. GNOME gives me all of them, Xfce gives me some, and MATE gives me none.

Composition still works in all cases, but apparently something differs enough that the browsers fail to provide JavaScript events properly.

All of this was tested using Chrome, Firefox, and Epiphany (WebKit).

[masayuki-nakano]

On macOS, a dead key sequence is handled as IME composition on macOS. Similarly, if you see typed dead character as composition string in Linux, the IME which you installed into your system handles it as IME composition on Linux.

On the other hand, dead keys are treated as 2 sets of key events on Windows.

So if browsers expose the native input events to DOM events directly, the former works only when editable element has focus. In this case, browsers may send "Dead" key events as keydown with Dead key value.

The problem to explain which character is being typing with a dead key press is, the value is fixed at the end of the sequence (i.e., may be not related to the final result) and the value should be a combining character or not. Technically, dead key can be mapped with any character, and if OS provides different form character from standardized one, browsers need to convert them to get same result on all platforms. However, it's hard to maintain the conversion.

[CendioOssman]

This is indeed a hard problem to solve. And it might only work reliably if IME is disabled, which is an option that needs to be made available for use cases such as ours.

It's not impossible, though. TigerVNC tries to deal with this case, and has code for Windows:

https://github.com/TigerVNC/tigervnc/blob/b59ddd0c8cc031321fbc05d0e1f42866ba7820be/vncviewer/win32.c#L340-L369

And for macOS:

https://github.com/TigerVNC/tigervnc/blob/master/vncviewer/cocoa.mm#L328-L344
https://github.com/TigerVNC/tigervnc/blob/master/vncviewer/cocoa.mm#L475-L485

[CendioOssman]

The new keyboard layout API seems to have started defining replacement symbols for dead keys:

https://wicg.github.io/keyboard-map/#dead-and-combining

Perhaps those could be used in the classical keyboard events in a new field?