Allan Jacobs
2010-09-29 21:56:23 UTC
Recommendations
===============
(1) Fix the keyup, keydown, keypress, compositionstart, and
compositionend events on Linux so that they report something besides 0
values. Dead key sequences foul up the assignment of attributes.
This is #1 because I can probably handle a bug fix of this complexity
myself.
(2) Add key and char attributes to key events as per the W3C DOM Level
3 Events specification.
(3) Implement the new textInput event as per the W3C DOM Level 3
Events specification.
Problems associated with key events are recorded in many bug reports.
Currently, I've
been working off of 447757.
Conclusions
===========
JavaScript events have attributes. Mozilla currently does the
following for key and text events:
(1) Assigns values to the attribute keyCode for keyup and keydown
events. The assignment is often wrong (null) on Linux.
(2) Assigns values to the attribute charCode for keypress events. The
assignment is often wrong (null) on Linux.
(3) Bungles the assignment of attributes to compositionstart and
compositionend on Linux
The W3C specification declines to specify what the correct values are
for assignments to charCode and keyCode. It makes recommendations for
the assignment of two new attributes: char and key. In principal,
these assignments could be made more less operating system and browser
independent.
(4) Firefox does not make assignments to either of the new char or key
attributes. In the tables below, no attempt is made to indicate the
lack of assignment. Assignment of both char and key look relatively
easy. The previous draft of the W3C DOM Level 3 Events specification
was more challenging.
(5) Firefox dispatches compositionstart and compositionend events on
Linux. On Windows the behavior is completely different. This is an
OS dependency that is difficult to code around.
(6) W3C calls for a textInput event to get fired after the last
keyup. If Firefox implemented this part of the spec then the OS-
dependency and browser-dependency it's current implementation is
requiring could be made to vanish -- at least for the majority of the
applications that listen to the keyboard.
In an earlier post on this topic, operating system inconsistencies had
not been determined. Now they are and they are large.
Supporting Data
===============
Mozilla key and text event sequences
Firefox 3.6.10
Test URL: https://bug447757.bugzilla.mozilla.org/attachment.cgi?id=474270
Nominal keyboard sequence (Windows: AltGr 2 e)
Country: Albania
Language: Albania
The tables record the event sequence in the order of occurence.
Windows
=======
keyC charC alt event
17 - F keydown
18 - T keydown
50 - T keydown
50 - T keyup
17 - T keyup
69 - F keydown
- 283 F keypress
69 - F keyup
Linux
=====
keyCcharC alt event
0 - F keydown
- 0 T keypress
0 - T keyup
0 - T keyup
- - T compositionstart
- - F compositionend
69 - F keyup
===============
(1) Fix the keyup, keydown, keypress, compositionstart, and
compositionend events on Linux so that they report something besides 0
values. Dead key sequences foul up the assignment of attributes.
This is #1 because I can probably handle a bug fix of this complexity
myself.
(2) Add key and char attributes to key events as per the W3C DOM Level
3 Events specification.
(3) Implement the new textInput event as per the W3C DOM Level 3
Events specification.
Problems associated with key events are recorded in many bug reports.
Currently, I've
been working off of 447757.
Conclusions
===========
JavaScript events have attributes. Mozilla currently does the
following for key and text events:
(1) Assigns values to the attribute keyCode for keyup and keydown
events. The assignment is often wrong (null) on Linux.
(2) Assigns values to the attribute charCode for keypress events. The
assignment is often wrong (null) on Linux.
(3) Bungles the assignment of attributes to compositionstart and
compositionend on Linux
The W3C specification declines to specify what the correct values are
for assignments to charCode and keyCode. It makes recommendations for
the assignment of two new attributes: char and key. In principal,
these assignments could be made more less operating system and browser
independent.
(4) Firefox does not make assignments to either of the new char or key
attributes. In the tables below, no attempt is made to indicate the
lack of assignment. Assignment of both char and key look relatively
easy. The previous draft of the W3C DOM Level 3 Events specification
was more challenging.
(5) Firefox dispatches compositionstart and compositionend events on
Linux. On Windows the behavior is completely different. This is an
OS dependency that is difficult to code around.
(6) W3C calls for a textInput event to get fired after the last
keyup. If Firefox implemented this part of the spec then the OS-
dependency and browser-dependency it's current implementation is
requiring could be made to vanish -- at least for the majority of the
applications that listen to the keyboard.
In an earlier post on this topic, operating system inconsistencies had
not been determined. Now they are and they are large.
Supporting Data
===============
Mozilla key and text event sequences
Firefox 3.6.10
Test URL: https://bug447757.bugzilla.mozilla.org/attachment.cgi?id=474270
Nominal keyboard sequence (Windows: AltGr 2 e)
Country: Albania
Language: Albania
The tables record the event sequence in the order of occurence.
Windows
=======
keyC charC alt event
17 - F keydown
18 - T keydown
50 - T keydown
50 - T keyup
17 - T keyup
69 - F keydown
- 283 F keypress
69 - F keyup
Linux
=====
keyCcharC alt event
0 - F keydown
- 0 T keypress
0 - T keyup
0 - T keyup
- - T compositionstart
- - F compositionend
69 - F keyup