keyboard / text / composition events on Linux

[Allan Jacobs]

I took a look at "dead-key" handling in the current build on Linux
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100910 Firefox/
4.0b6pre

Bug 447757

To frame the problem, suppose you are typing in a super-ASCII
language. I picked
Albanian because it requires less scrolling while debugging. The
AltGr key is
normally the key marked "Alt" immediately to the right of the
spacebar. The "Alt"
key to the left is the Alt key - not the AltGr key.

The following sequence of keystrokes, typed on a standard (American)
PC keyboard
1. down AltGr
2. down 3
3. up 3
4. up AltGr
5. down e
6. up e
generates an 'e' with a circumflex '^' above it. Unicode value
\u00ea.

Strictly speaking, Linux and MacOS simulate dead-key behavior with
input methods
(IME). The code in Firefox certainly reflects this: it uses IME
events
compositionstart and compositionend to communicate keyboard
manipulations.

Issue Set #1: bugs
==================

The event sequence generated contains a number of errors. The first
column marks what is typed. kCode is short for keyCode, an attribute
of the DOM event. cCode is short for charCode, another attribute
of the DOM event. data is an attribute of CompositionEvents, or at
least should be. alt values are all false, which is correct as the
Alt key was not depressed. type is the DOM event type.

Browser: Firefox
Keyboard: Country=Albania, Language=Albania
Press AltGr, press 3, release 3, release AltGr, press e, release e
------------------------------------------------------------------
kCode cCode data alt type
Alt 0 - - false keydown
Alt - 0 - false keypress
3 0 - - false keyup
Alt 0 - - false keyup
e - - undef - compositionstart
- - undef - compositionend
e 69 - - false keyup

1. The second event is a keypress event for a key without a character
representation. 0 is not valid. The keypress event for the AltGr
key should never be dispatched.
2. The third event is a keyup event that lacks a matching keydown
event.
3. The specification is ambiguous as to whether there should be a
keydown
event generated just before IME processing begins (when
compositionstart
events are born). Personally, I like what Firefox is doing here.
4. The fifth event is a compositionstart event without an assigned
data
attribute. This is very wrong.
5. The sixth event is a compositionend event without an assigned data
attribute.


Issue #2: textInput
===================

Has a decision been made to never dispatch textInput events? The W3C
level 3 event specification draft says that textInput should be
dispatched
automatically after keypress and compositionend events, unless
explicitly
suppressed.

This is true on Windows, not just Linux.

What is the behavior of Firefox on Windows? Does it dispatch
compositionstart and compositionend events? textInput events? Or does
it generate keypress events as it has in the past?

Depending on the answers to these questions, a textInput event a la
W3C
Level 3 Event specification would make it easier to write OS-
independent
code for Firefox.

Webkit hides the IME used underneath (on Linux). compositionstart and
compositionend events are not generated. Two event sequences
are documented below.

Browser: Chrome 5.0.375.127 (55887) Ubuntu 10.04
Keyboard: Country=Albania, Language=Albania
Press AltGr, press 3, release 3, release AltGr, press e, release e
------------------------------------------------------------------
kCode cCode data alt type
Alt 0 - - false keydown
3 229 - - false keydown
3 51 - - false keyup
Alt 0 - - false keyup
e 69 - - false keydown
e - 234 - false keypress
- - ê false textInput
e 69 - - false keyup

Browser: Chrome 5.0.375.127 (55887) Ubuntu 10.04
Keyboard: Country=Albania, Language=Albania
Press AltGr, press 3, release 3, release AltGr, press e, release e
------------------------------------------------------------------
kCode cCode data alt type
e 69 - - false keydown
e - 101 - false keypress
- - e false textInput
e 69 - - false keyup