Typeahead: Allow controlling selection trigger keys

[christor]

Currently, typeahead treats either a Tab or Enter key as a trigger to select the currently-highlighted option. This is probably a sensible default for many use cases.

I have a particular use case where I'd like to make it so that a tab does not trigger selection, but instead simply moves to the next form field. For my use case, a simple typeahead-select-on-tab="false" or something similar would suffice.

A more general thought might be to allow arbitrary keys/combinations to trigger completion, or a callback function for determining this (something like typeahead-is-trigger-key="vm.isTriggerKey($event)").

Before I go off generating a pull request...Is there some support for something like that that already exists? Any thoughts on the idea? Implementation/naming?

[wesleycho]

This request has accessibility ramifications - can you explain why do you want it to close the typeahead without selecting on tab?

[christor]

Our form has multiple fields. We'd like our input to allow both free-form entry as well as selection from a list. In order to allow consistent navigation between form fields, we'd like to make it so that Tab only switches to the next input without selecting the option. The option can still be selected by pressing Enter.

Just to clarify: this request is not to change the default behavior, but specifically to allow the option to prevent Tab from triggering a selection.

[christor]

@wesleycho Any further thoughts on this feature idea? Or perhaps a simple workaround? I'll begin working on a workaround this week or next. It seems typeahead-select-on-tab="false" will be the least amount of change, so that may be the route I'll take. If you're interested, I'll turn this into a pull request. Any guidance is appreciated.

[deeg]

@christor I believe you could accomplish what you want today by using typeahead-on-select="select($item, $event)"

Would you not be able to check which key was pressed on the event object and handle different logic accordingly?

[christor]

@deeg Thanks. That doesn't quite work because by the time the callback is made the value has already been replaced in the input field. I can't simply return false from the handler to cause it to not set the value (although maybe that's another way to consider handling this?).

So the best I could think do without modifying angular-ui/bootstrap would be to add another keyup event handler to remember the old values that were typed...then if I see a tab was pressed, to set it back to its old value (kind of ugly)...

[christor]

@christor, could you use typeahead-editable $ (Default: true) - Should it restrict model values to the ones selected from the popup only? so that the model value does not get updated before going into that callback?

Thanks, I'll give that a shot.

For my use case I do not want to restrict the user to the choices in the
popup (sorry I didn't make that clear sooner). They should be able to type
a new value or choose.

[rcollette]

+1

[wesleycho]

Please do not post +1s, it adds noise to the issue thread.

[christor]

My earlier reply about typeahead-editable was to a message that seems to have since been deleted...

Unless I've misunderstood, it doesn't appear to suit my need since I need to allow a custom value to be entered that isn't on the list.

[christor]

Here's a plunker with a workaround that comes close to the behavior I'm looking for:

http://plnkr.co/edit/jtKEcKLN5RGDrldb31Gd?p=preview

It saves the current model on keyup, then on keydown with a Tab it restores to the value as it was at the last keyup. It's a bit awkward to do this way, so I'd prefer to have the typeahead manage this on its own.

If it's unlikely a patch to add an option to change the behavior will be accepted, I'll use this work-around. If a patch would be considered, I'll work on something today.