Is it possible to ignore keydown events with keyCode = 229?
In the beginning, I wanted to track changes in <input type="text"> in real time (for example, exactly when the user presses a key). The onChange event onChange not fire, because it fires only when the user presses Enter or removes focus from the input element. Then I saw this question in StackOverflow. I tried the code from this answer, but the problem is that I do not want to receive notifications about keystrokes that are not printable characters, so I had to change it in such a way as to make sure that there are printable characters in the events
... textInputElement.onKeyDown.listen((KeyboardEvent ev) { if (new String.fromCharCode(ev.keyCode).length > 0) { callAFunction(); } }); ... (+ same change for onKeyUp event)
When I tested this in Dartium, I saw that by focusing the input element and then pressing any key, the keydown event fires with ev.keyCode = ev.which = 229 and ev.charCode = 0 . Immediately after this event, another keydown event is keydown with the correct ev.keyCode = ev.which and ev.charCode = 0 . I did not understand where this key 229 came from, but I saw that it was a printed symbol, å . I searched the Internet, and I found that others have this problem, and sometimes they use other programming languages and technologies. One relevant this link, and the hotfix chosen, is in this very small commit - they decided to ignore all events with keyCode = 229 with the explanation that recent versions of Chrome / Chromium / WebKit started sending these keydown events before each standard keyboard event and what their meaning is in that the user has pressed some buttons. but the input method still handles the input / input editor handling the key input.
My question is: is it okay to ignore keydown events with keyCode = 229 if new String.fromCharCode(229) returns the printable character " å "? I thought about a possible situation with the presence of a real key that creates the same key code and the corresponding character.
I thank you for any help!
Short answer: None. You can ignore keydown events with keyCode = 229, but only if they follow immediately after a keypress event.
If you hold certain keys, some browsers send a keydown event again with a keyCode value of 229, while others send the keydown source code again. Some browsers send 0 as the key code associated with a keypress event, and put the character code in the 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. The following are the events received in Safari 6.1.5 when the keyboard is set to Swedish or Finnish and the å symbol is pressed (to the left of the P key):
EVENT keyCode keydown 219 ("[" key position) keypress 229 (å) keydown 229 (repeatedly, indicating that the Input Monitor is busy) keyup 219 Note that the initial keydown keyCode is 219, not 229.
To generate 229 keyCode in the original keydown event, you can press any dead key. For example, on a Swedish keyboard on a Mac, the key to the left of the BACKSPACE key is "(acute accent), 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 enter a character that can be combined with it, the browser can replace the initial dead key character with a compound character ('+ e = é), which has its own Unicode value.
The following are the events you will see in Safari 6.1.5 when the user presses and releases, and then e on the 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 at all, because there is no “é" key as such that was pressed. If you want to determine which character the user entered, you can wait until the second key press, then read the character from the input field.
In other words, you can ignore any keydown events with 229 keyCode after a keypress event, but if you ignore all 229 keyCodes, you can prevent users from adding various diacritical characters.
For more information on keyCode 229, from w3.org: the keyCode property of key events