You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(this concerns the numeric text field for me, might be applicable to more)
Explicitely checking for and allowing things like ^V, ^Z, etc. breaks common browser functionality like opening a new tab with ^T. Any hotkeys defined by users will also be denied for no good reason.
The text was updated successfully, but these errors were encountered:
Seconding this, it's functionality that breaks the user's mental model of a text field and should be a bug.
The current strategy to parse input seems to be to broken into two parts:
Whitelist key inputs on keypress
Clean input on keyup
deals with situations like copy+paste
The whitelist model is broken because it prevents users from using other shortcuts that they may be used to, such as ctrl+a to select the entire text.
Because there isn't an accurate way to determine if the keystrokes will or will not produce any text, I think a better approach is:
Blacklist known character ranges on keypress
alphabetical characters, other unicode values, but not modifiers
Clean input on keyup
A blacklist is much more flexible in handling the variety of possible user input that the current whitelist, and the cleaning step is necessary in either case.
(this concerns the numeric text field for me, might be applicable to more)
Explicitely checking for and allowing things like ^V, ^Z, etc. breaks common browser functionality like opening a new tab with ^T. Any hotkeys defined by users will also be denied for no good reason.
The text was updated successfully, but these errors were encountered: