See issue
http://bugs.jqueryui.com/ticket/7423. This problem is that you can get an autocomplete to show its menu when it doesn't have the focus. This is no big deal, until you have two autocompletes side by side, and then you get situations where both are showing their menu at the same time, which is confusing and looks bad.
To reproduce, go to the autocomplete example with remote data, and type 'ro', then just when the spinner comes up, press the tab key. If you time it just right, the menu will stay up, and focus will be gone.
In trying to fix this, the source of the issue is the following sequence of events:
- User types a few keys
- source function is called
- User presses tab key
- blur fires off a timer to close things down
- response from step 2 comes back, and cancels the timer
- menu pops up, focus is elsewhere
In trying to fix this, I first tried to test that the field had focus. But that broke the ability to popup the menu using a autocomlete('search') call.
Then, I tried to use the timer itself as a test, but that causes a different scenario to have the same problem.
- User types a few keys
- source function is called
- User presses tab key
- blur fires off a timer to close things down
- timer comes back, closing things down
- response from step 2 comes back, popping up the menu
Attempting to detect the timer in the response is tricky, because the timer might come back before, or after the response, or the response might not ever return for some reason.
Since we are allowing the source to be any kind of function call, we can't just try to cancel the response during the blur event, unless we do some kind of complicated tracking of the response, giving the function call and id, and timing out the response.
One solution might be to have another flag to record the firing of the blur event, and then in the response, don't popup if the blur was fired. This blurring flag would have to be reset in the in the _search function.
However, as I think about it, I am wondering if it ever makes sense for the autocomplete to popup its menu if it does not have the focus. If we can force the field to have the focus as part of the autocomplete('search') function, then its all a fairly easy fix. Obviously, to do that, we might break someone's code that is relying on being able to popup the menu with a button, but have focus somewhere else. But again, I wonder if such a use makes sense for an autocomplete. After all, its not like its a real menu, or a list. Conceptionally, its a field, and should have the focus when its manipulated. In fact, if we don't do that, then we could always have the case where two menus are popped up simultaneously, with the following steps:
- Two autocompletes on a page, and a button that pops up the menu for ac #1
- Focus is in ac #2, no menu yet.
- Button is pushed, bringing up menu for #1
- Letters are typed, bringing up menu for #2 and not bringing down menu for #1
I would think we would want to prevent that situation by default, and if the developer REALLY wants to let something like that happen, then they have to write the code for that strange situation.
Thoughts?