Closed Jemt closed 3 years ago
Both charCode and keyCode are deprecated. We should probably expose Fit.Events.GetKeyCode(evArg)
which uses modern APIs when available, and revert to legacy APIs when not. Also supply Fit.Events.GetKeyChar(evArg)
which on modern browsers leverage the .key property, while on older browsers use something like String.fromCharCode(evArg.charCode || evArg.keyCode)
.
Remember, we can trust evArg.keyCode to return a real character code just like evArg.charCode when evArgs.type returns "keypress", while for OnKeyDown and OnKeyUp, the keyCode might represent any key, which might produce odd results when passed to String.fromCharCode(..) - for instance keyCode 119 (F8) results in a return value of "w" while the meta key (e.g. Cmd key on Mac) returns "[".
We probably want Fit.Events.GetKeyChar(..) to return "" when keyCode is in the range of 0-46 (excluding: 9 = tab (\t), 13 = line feed (\r), 32 = space), and 91-222 (http://gcctech.org/csc/javascript/javascript_keycodes.htm).
Also see https://stackoverflow.com/questions/7694486/browser-key-code-list
This issue is no longer relevant since the introduction of a new layout model for selected items - see #120. The code has been removed. The suggested implementation of Fit.Events.GetKeyCode(..) and Fit.Events.GetKeyChar(..) has been moved to a new issue: #123
Due to use of unsupported (in IE8) charCode property in DropDown, input fields in the DropDown does not assume the correct width when typing, causing characters to become hidden.
We could probably do something like
var charCode = ev.charCode !== undefined ? ev.charCode : ev.keyCode
instead. However, charCode only contains a value when a real character is pressed while keyCode always has a keyCode representing the key pressed. But it seems, according to spec (https://developer.mozilla.org/en-US/docs/Web/API/Document/keypress_event), that OnKeyPress should only be fired when character keys are pressed: "The keypress event is fired when a key that produces a character value is pressed down." The ENTER key (also in combination with SHIFT and CTRL) seems to be an exception to this. It does not fire for e.g. Backspace, Delete, Function keys, etc. when tested with Chrome 86 on macOS. If this is also the case on Linux and Windows, using the keyCode instead should be fine - in that case we can completely ignore charCode.Test with
ev.keyCode
on Mac, Windows, and Linux in various browsers, and make sure to ignore the ENTER key (keyCode 13).