Special handling for inputs
Opened this issue · 6 comments
In most cases, we will not want our keyboard responders to trigger while in a textarea or input field. However, in other cases a developer might want to opt-in, such as with a text editor that italicizes with keyUp:ctrl+i. Perhaps we should allow key responders on components with tagName: 'input' or tagName: 'textarea', but these key responders will by default be bubble: false.
In all other cases, if the focus is in an input field, then the event listeners should not fire.
This is the issue that ember-key-responder faced and they decided to opt inputs/text-areas in automatically. Inputs and textareas were simply added to the responder stack when they were focussed. It makes sense to do it this way logically, keep all key events as part of the key responder system, but in practice I found it difficult to work with.
Maybe all components should have the ability to state whether or not they bubble key events if focussed? Many other elements can be focussed, it doesn't really make sense to have a special case for input and textarea.
What makes inputs/textareas special is that users will often be pressing keys while they're focused. This could lead to awkward situations where the user tries to type their name 'Chris', but as soon as they press s, it triggers a key responder that causes the app to refocus to the searchbar.
That being said, I like the idea of components being able to opt-out of event bubbling when focused. Currently, we can even achieve this effect by making a component firstResponder on focus-in and then setting keyboardBubbles to false. We could make a simple mixin with all that bundled in.
On the other hand, there's a pretty serious cost to this approach. In order for devs to opt-out, they'll have to create a component to add this mixin to. Doing that for every input in a pre-existing app would be prohibitive. Even for devs working on a new app, it'd be better not to force them to create a base-input component that has this mixin. I'd prefer that we leave devs to build their apps using the patterns they find best, even if that means sticking with the default input helper.
So what do you think of an opt-in approach? By default, keyboard events won't trigger ember-keyboard responders while an input/textarea is focused. However, if the dev opts-in to event bubbling, then ember-keyboard will handle the event.
Another thought: really what we're trying to prevent here is interference between normal input/textarea typing and special hotkey commands. While focused on an input/textarea, what if ember-keyboard ignored all keyboard events that weren't being modified with ctrl, alt, or meta, or that used keycodes greater than 37? (Keycodes 37+ are letters, numbers, backspace, delete, and the arrow keys.) This way for instance, they could still press ctrl+alt+l to open the login dropdown or Escape to close the currently opened modal. That should account for ~99% of use cases, and we can still have devs opt-in to do things manually if they prefer.
I think for now we should avoid having special rules about when the key responder bubbles and when it doesn't, it makes the system harder to reason about and if we get it wrong we'll have to support that for a while at least.
I also definitely agree that inputs/textareas should opt-out of bubbling by default. By default when focussed they should prevent any key responder action, and a hook should be added to override this behavior. We can reopen the input and textarea classes to accomplish this. We can also reopen the component class to add the hook in the first place. So, hook is added in Component -> activated by default in Input and TextArea.
Sounds good to me. This one should be next on the docket.
Thanks for ember-keyboard! Am not sure if this issue has been addressed earlier but am using the 2.3.0 version of ember-keyboard and my key responders get fired when the user is typing in an input. Is there any setting required to turn off responders in input/text area?