问题
At the beginning I wanted to monitor changes to a <input type="text"> in real time (for example, exactly when the user presses a key). The onChange event did not work because it is triggered only when the user presses Enter or removes focus from the input element. Then I saw this question on StackOverflow. I tried the code from that answer but the problem is that I do not want to be notified for key presses that do not represent printable characters, so I had to modify it in this way to make it verify that there are printable characters in the events:
...
textInputElement.onKeyDown.listen((KeyboardEvent ev) {
if (new String.fromCharCode(ev.keyCode).length > 0) {
callAFunction();
}
});
...
(+ the same change for the onKeyUp event)
When I tested this in Dartium I saw that by focusing the input element and then pressing any key, a keydown event is triggered with ev.keyCode = ev.which = 229 and ev.charCode = 0. Immediately after this event, another keydown event is triggered with the correct ev.keyCode = ev.which of the pressed key and ev.charCode = 0. I did not understand where this 229 key was coming from but I saw that it is a printable character, å. I searched the Internet and I have found that others have this issue, and sometimes they are using other programming languages and technologies. One relevant link is this and the chosen fix is in this very small commit - they chose to ignore all events which have keyCode = 229 with the explanation that recent versions of Chrome/Chromium/WebKit started to send these keydown events before every standard keyboard events, and that their meaning is that the user pressed some button. but input method is still processing that or input method editor is processing key input.
My question is, is it OK to ignore keydown events with keyCode = 229 if new String.fromCharCode(229) returns the printable character "å"? I thought about the possible situation of having a real key that produces the same key code and its corresponding character.
I thank you for any kind of help!
回答1:
The short answer is No. You can ignore keydown events with keyCode = 229, but only if they follow immediately after a keypress event.
If you hold certain keys down, some browsers send a repeated keydown event with a keyCode value of 229, while others send the original keydown keyCode again. Some browsers send 0 as the keyCode associated with the keypress event, and place the character code in a charCode property.
In all cases, as far as I can tell from my tests, the order of events is always predictable:
keydown (event.keyCode = key-keyCode ex: 65 = "A")
keypress (event.keyCode = 0 | character-keyCode ex: 97 = "a") - conflated model
event.charCode = character-keyCode - split model
keydown (event.keyCode = 229 | key-keyCode ex: 229 | 65) - may be repeated
keyup (event.keyCode = key-keyCode ex: 65)
The letter å is used in a number of Scandinavian languages. Here are the events received in Safari 6.1.5 when the keyboard is set to Swedish or Finnish, and the å character (to the left of the P key) is pressed:
EVENT keyCode
keydown 219 ("[" key position)
keypress 229 (å)
keydown 229 (repeatedly, indicating that the Input Monitor is busy)
keyup 219
Notice that the initial keydown keyCode is 219, not 229.
To generate a 229 keyCode on the initial keydown event, you can press any "dead key". On the Swedish keyboard on Mac, for example, the key immediately to the left of of the BACKSPACE key is ´ (acute accent), as used in words like déjà-vu. When you press a dead key, the character appears in the input field, but the insertion point does not move. When you subsequently type a character that can be combined with it, the browser may replace the initial dead key character with a composite character (´ + e = é) which has its own Unicode value.
Here are the events that you will see in Safari 6.1.5 when the user presses and releases ´ followed by e on a Swedish keyboard:
EVENT keyCode
keydown 229 (dead key)
keyup 187 (acute accent)
keydown 229 (second key is being treated)
keyup 69 ("E")
Note that there are no keypress events sent at all, because there is no "é" key as such which has been pressed. If you want to determine which character the user entered, you can wait until after the second keyup, then read the character from the input field.
In other words, you can ignore any keydown events with a 229 keyCode after a keypress event, but if you ignore all 229 keyCodes, you may prevent users from adding various diacritical characters.
For more information on keyCode 229, from the w3.org site: keyCode property of key events
来源：https://stackoverflow.com/questions/25043934/is-it-ok-to-ignore-keydown-events-with-keycode-229