Search and Top Navigation
#9203 closed bug (invalid)
Opened April 03, 2013 03:51PM UTC
Closed April 18, 2013 08:35AM UTC
Search cancelled when triggered on select (regression from 1.8)
| Reported by: | BigBeaule | Owned by: | BigBeaule |
|---|---|---|---|
| Priority: | minor | Milestone: | none |
| Component: | ui.autocomplete | Version: | 1.10.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
It's now impossible to trigger another search during the select callback. I have a single input field that will first show suggestions for a property A. Once selected, the input is supposed to show suggestions values for the property A right away:
.autocomplete{
minLength: 0,
source: function( request, response ) {
... some Ajax source that is working fine
},
select: function( event, ui ) {
... adapted for ticket
if ( A === null)
// Switch to property value selection
A = ui.item.value;
input.autocomplete('search');
return false;
}
VAL = ui.item.value;
return true;
}
});
While searching the cause, I found that it's happening in the usage of the newly menu widget. If you look at line 284 (handler when selecting a value):
if ( false !== this._trigger( "select", event, { item: item } ) ) {
this._value( item.value );
}
// reset the term after the select event
// this allows custom select handling to work properly
this.term = this._value();
this.close( event );
this.selectedItem = item;
The close event is called after the trigger on the select callback and since close is setting cancelSearch at true on any case, I can't prevent my triggered search to be cancelled. I notice that both putting the line this.close( event ) before the select trigger or using this._close( event ) instead is fixing my problem, but I haven't done enough tests to see if there's any other consequences.
Working jsFiddle (only have to switch between jquery UI 1.8.9 and 1.9.2 to see the difference) http://jsfiddle.net/DYWZG/13/
Attachments (0)
Change History (6)
Changed April 03, 2013 08:37PM UTC by comment:1
| owner: | → BigBeaule |
|---|---|
| status: | new → pending |
Changed April 03, 2013 08:54PM UTC by comment:2
| status: | pending → new |
|---|
The difference between the 2 version is that after selecting the first property (A for example), the autocomplete input should be reopened right away with the possible values of property A (A1, A2 and A3). It works with jQuery UI 1.8.5 or 1.8.9 (ugly display because of the css, but still) while the automatic reopening is aborted with jQuery UI > 1.9.
My utilization context is that a user must give a desired property and its desired value to my application. I use the same autocomplete input to provide the suggested properties and its values.
The current glitch is just that as soon as the property is selected (I.E. an item is selected in the autocomplete suggestions), I trigger a search on the same autocomplete in the select callback in order to retrieve and display all the values for the selected property without having the user do anything in the input field. The retrieval is working fine but the reopening of the suggestions menu is cancelled because of the order of the internal trigger('select') and this.close( event ).
For the fix, I was suggesting to use _close instead. I found that it was causing some glitches but putting the this.close( event ) before the trigger('select') seems to be ok.
Changed April 03, 2013 09:01PM UTC by comment:3
| _comment0: | > The difference between the 2 version is that after selecting the first property (A for example), the autocomplete input should be reopened right away with the possible values of property A (A1, A2 and A3). It works with jQuery UI 1.8.5 or 1.8.9 (ugly display because of the css, but still) while the automatic reopening is aborted with jQuery UI > 1.9. \ \ I'm not seeing that behavior with 1.8.9: http://jsfiddle.net/DYWZG/14/ \ \ > My utilization context is that a user must give a desired property and its desired value to my application. I use the same autocomplete input to provide the suggested properties and its values. \ \ That's a bit confusing. Also, at least from the fiddle, it's impossible to then go back and choose a different top level location. Why can't use just use a timeout if the closing is a problem? → 1365024956399962 |
|---|---|
| status: | new → pending |
The difference between the 2 version is that after selecting the first property (A for example), the autocomplete input should be reopened right away with the possible values of property A (A1, A2 and A3). It works with jQuery UI 1.8.5 or 1.8.9 (ugly display because of the css, but still) while the automatic reopening is aborted with jQuery UI > 1.9.
I'm not seeing that behavior with 1.8.9: http://jsfiddle.net/DYWZG/14/
My utilization context is that a user must give a desired property and its desired value to my application. I use the same autocomplete input to provide the suggested properties and its values.
That's a bit confusing. Also, at least from the fiddle, it's impossible to then go back and choose a different top level location. Why can't you just use a timeout if the closing is a problem?
Changed April 03, 2013 09:32PM UTC by comment:4
| status: | pending → new |
|---|
I was using the option jQuery 1.x (edge) coupled with jQuery UI 1.8.5 and it was reproducible only cause of a js error happening I guess. My application uses an ajax source that seems to be returning just after the normal close and since they are handled differently in 1.8 vs 1.9, the behaviour is not the same. I'll try to think of a way to put that in fiddle tomorrow.
I must add that my application offer all the feature to go back and forth between selected properties and their values of course. I just put a minimalist display here.
Changed April 03, 2013 09:35PM UTC by comment:5
| status: | new → pending |
|---|
Changed April 18, 2013 08:35AM UTC by comment:6
| resolution: | → invalid |
|---|---|
| status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
I don't see any difference in behavior with 1.8.9 and 1.9.2 in that fiddle. Also, it's not clear what steps you want us to take to reproduce the problem. Can you clearly describe the steps to reproduce, the expected behavior, and the actual behavior?
Why are you running a search after selecting a value? Why is that dependent on a previous value having already been selected? There is no context to what is happening and I find this fiddle extremely confusing.