Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Browser controls and user-defined functionality broken #25

Open
akaIDIOT opened this issue Oct 8, 2011 · 1 comment
Open

Browser controls and user-defined functionality broken #25

akaIDIOT opened this issue Oct 8, 2011 · 1 comment

Comments

@akaIDIOT
Copy link

akaIDIOT commented Oct 8, 2011

(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.

@wylieconlon
Copy link

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:

  1. Whitelist key inputs on keypress
  2. 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:

  1. Blacklist known character ranges on keypress
    • alphabetical characters, other unicode values, but not modifiers
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants