As previously discussed at tague's key handling meeting, we need to have the translation between virtual key codes (VKC) and character codes, before the nsKeyEvent gets propagated. This requires work on each platform to get the character code from platform-specific event data. This bug is a followup to bug 2213, and was opened to keep track of this specific requirement.

adding ftang and myself to the cc list

Yes, this needs to be done but its really platform work for the widget libraries. I can add a new field into nsKeyEvent to hold the character code data and make sure it gets represented internally but platform specific widget libarary stuff isn't really my bag. Actually, do we need three bugs for this to keep it clear?

It would seem that capturing the OS event and propagating an nsKeyEvent with the char code in it falls under the layout umbrella. I agree that handling the key events at the other end is widget/ender work; all we need for now is the key event propagation to get fixed. So if you could do the first part, that would be great.

That's fine. I'm signed up to ensure that within the layout engine key events get to the right place. My point is that that has nothing to do with this specific bug with the possible exception of adding a field to nsGUIEvent. As the bug points out, this translation needs to happen before the nsKeyEvent is propagated. Someone else should take this.

You're saying that the event capture and propagation lives in platform-specific code. If so, please add the charCode field, and make 3 new bugs with platform owners to implement it.

Mail/news needs this for dogffood. You can't type punctuation characters now. Making P1.

Reassign to sdagley, who owns this for now.

QA contact re-assigned according to the product areas we're currently working on.

The character code is now available on Mac and Linux. Rods will be checking in the required code for Win32 in the morning.

rods has checked in already. When the tree goes green, I'll build and see what works.

rods, there are still problems on Windows with some keys. The problem is that the keyCode field of nsKeyEvent must contain one of the enum values in nsIDOMEvent.h (also in nsGUIEvent.h), and not the nChar that comes in. The problem is that keyCode is being set to values that have special meanings, which means that switch(keyCode) statements elsewhere in the code base fail. For example, if the char is '.', this may map to VK_HOME, which would be interpreted as the Home key. Now perhaps you see why that enum of VK_ codes is so evil. The solution we've done on Mac and Linux is this: if the key event corresponds to some special key (e.g. non-printable chars, like arrows, return, home, end etc) then figure out the right VK_ enum value, and put that in the keyCode. Otherwise, set the keyCode to 0. See nsGtkEventHandler.cpp for an exmaple.

Oh, wait. I needed to throw a switch in the editor to handle key codes properly. Duh. Typing works better now. The the question now is, is the keyCode field always getting the correct value, because the enum of VK_ values just (magically) happens to correspond to key codes on Windows keyboards?

Just to clarify - rods checked in the code to fill in the character code so this bug is technically fixed but sfraser has some additional questions on the Windows keyCode vs. the Gecko virtual key codes

*** Bug 2213 has been marked as a duplicate of this bug. ***

email from rods: We deliberately made the mappings be identical on one platform and than had the others do extra work to map it, instead of having all the platforms map it. The keyCode SHOULD be correct and always there, but tague has changed all my code to support I18N, so I can no longer guarantee it. Rod