We know that there are many keyboard layouts in the world. When we compute a keycode for each key which can input a character, we need a clear rule which is useful on all platforms. On an old DOM3 Events draft gave some hints for us. Now, I think we should use following rules: 1. If the key can input an alphabet or numeric, it is DOM_VK_[A-Z0-9] (See bug 447757). 2. If the key can input a white space, it's DOM_VK_SPACE. (See bug 479942) 3. For the other keys which input ASCII character, they are computed from unshifted character. 4. For the other keys which input non-ASCII character, they are computed from shifted character if the shifted character is an ASCII character. 5. Otherwise, we should use 0. For using these rules, we need to define more keys for non-letter characters such as ':', '@' and '<' which are not in unshifted position of US keyboard layout because such characters may be inputtable without shift key on some keyboard layouts. Note that by these rules, the computed keycode will be based on its unshifted character. But if the key is numeric keys of AZERTY, its keycode is computed as NS_VK_[0-9]. By this change, some web applications which are handling keydown event and keyup event might be broken on some keyboard layout. But I think that such application is rare because: 1. It's too difficult for handling non-letter keys for cross platform and cross browser. 2. This change doesn't break the behavior of keypress event. I guess that most web applications which need to handle key event is using keypress event rather than keydown and keyup events. If you have some suggestions, please comment here.
I posted a patch for cocoa in bug 677252.
keycode reimplementation is now fixed. I'll implement .key and .char ASAP. It must help to fix some bugs.
sgautherie: Note that, a lot of tests are landed actually: For Windows: http://hg.mozilla.org/mozilla-central/diff/e9e804a67d29/widget/tests/test_keycodes.xul For Mac: http://hg.mozilla.org/mozilla-central/diff/29e512736f30/widget/tests/test_keycodes.xul