when searchEnabled is false shortcuts in list do not work

[lvostinar]

see http://plnkr.co/edit/fC6Cz0Foy55JvkUvwoDp?p=preview

I cannot use enter,up/down arrows when list is open; if searchEnabled is true shortcuts work

[Jaxsun]

I also have this issue with ui-select. Without a search box focus is lost, you can tab and eventually focus on the drop down which allows keyboard controls, this focusing should happen immediately when the drop down opens.

[aeisenberg]

I see the problem is that focus and keyboard events are handled through a the search element, which is hidden in this case. This code is the culprit:

var _searchInput = $element.querySelectorAll('input.ui-select-search');

(Line 106 in version 0.9.3)

To fix, need to attach listeners to a different element.

[davideanderson]

+1

[sagivf]

+1

[aeisenberg]

This solution is kind of a hack. I'm not a big fan of it myself.

[sagivf]

@aeisenberg The only alternatives I can think of are:

1. Add a wrapper and keep the input in a lower z-index - a bit of a hassle, not sure it would work.
2. Registering to events on the body when the drop down is open - very error prone

What do you think?
I think your solution is reasonable(a little hacky, but not that bad), perhaps just increase the offset for edge cases.

[aeisenberg]

I seem to remember that there were some edge cases that didn't work properly, but I can't remember what they were. Honestly, I created the fix 6 months ago and don't remember everything.

I don't think your suggestion 1 will work since I think that the events need to be attached to the search box, which is the element that gets focus. For the same reason suggestion 2 won't work.

The truth is that I am torn about this fix. It is not great, but I can't think of a better way. If the fix does work properly, then it's probably good enough, but I'm not confident that it does in all cases.

[sagivf]

@aeisenberg Thanks for you input.

Regarding - 1) - I mean moving the input to a different z-index after the focus.
and 2) means we handle all the key event's separately on the body, again this is defiantly very complex and error prone, but it's less hacky but I still wouldn't event go into it.

Do you still think number 1 won't work?

[aeisenberg]

Hmmm...#1 might work. If you want to take a crack at it, I'll be happy to
review it.

On Mon, Jun 15, 2015 at 9:52 AM, Sagiv Frankel notifications@github.com
wrote:

@aeisenberg https://github.com/aeisenberg Thanks for you input.

Regarding - 1) - I mean moving the input to a different z-index after the
focus.
and 2) means we handle all the key event's on separately on the body,
again this is defiantly very complex and error prone, but it's less hacky
but I still wouldn't event go into it.

Do you still think number 1 won't work?

—
Reply to this email directly or view it on GitHub
#331 (comment)
.

[asapach]

To fix, need to attach listeners to a different element.

Perhaps there should to be a container element with tabIndex of 0 (instead of the input "focusser") that will hold the focus and handle all the keyboard events?

[wesleycho]

Can you post a more up to date Plunker based on the latest release?

[Jefiozie]

@aaronroberson or @user378230 , looks like it is fixed as I cannot reproduce it any more with the latest.
Don't forget to close down PR #570

[user378230]

Closed by #1717