We’re working on a fairly high-profile application that relies on Ajax for input filtering, and came away with some pretty hard lessons learned.

The core problem is this: Javascript keystroke events can often be unreliable for alphabets in which a single keystroke does not equal a single character. Reliance upon onkeyup, onkeypress or onkeydown events can cause problems in these languages.

In alphabets such as Hiragana (Japanese) or Hangul (Korean), characters are typically created by multiple keystrokes. Thus a single keystroke may generate a temporary character, which is converted into a complete character with additional keystrokes. This conversion is typically handled at the OS level.

For example, in Korean the last name “Kim” is a single character that is composed of three keystrokes.

The problem with this is that Javascript keystroke event processing is spotty in this scenario. In Firefox for Windows, when typing in Japanese’s Hiragana only the first key press triggers an event. After the first keystroke, the character conversion software takes over and Windows essentially doesn’t trigger onkeyup, onkeypress or onkeydown events. It’s as if the user didn’t type anything.

Internet Explorer on Windows often triggered onkeydown and onkeyup events, but not in all cases. For both browsers, the key code for events was often altered.

Since our application relies on user input to capture field values (for result set filtering purposes), and absolutely must support languages that use character conversion (such as Japanese, Korean and Chinese), this is a major problem.

After much testing and confirmation, the solution we ended up with is to not rely on keystroke events at all. The approach we’re using is a watcher loop that looks for changes in the text entry fields on a periodic basis. This brings with it a number of other challenges, but at least we have something working.