Search and Top Navigation
#7926 closed bug (notabug)
Opened December 01, 2011 09:46AM UTC
Closed February 11, 2012 06:04PM UTC
Autocomplete: Race condition with autoFocus
Reported by: | brstgt | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.9.0 |
Component: | ui.autocomplete | Version: | 1.8.16 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
This is a duplicate of #7555. But please don't close without having a close look.
I claim, that the bug still persists.
The Problem is systematic, since the autoselect relies on a state that was defined in the past and does not react on state changes in the meantime. So it is not "serializable"
I try to explain the race condition:
1 = async thread 1
2 = async thread 2
This happens sequentially as listed:
- I type "jav"
1 waiting 300ms (default delay)
1 AJAX request is triggered
2 Before ajax is finished, I type "a"
2 ... "a" triggers just nothing, because 300ms have not timed out ...
1 AJAX call returns
1 Autoselect selects the first hit (search term 'jav') and fills the input field with 'jav'
Where is my 'a'??
I could reproduce this behaviour in 1.8.16 and 1.9m6
My solution suggestion:
Implement a proper debouncing mechanism!
1. Each time I press a key, the delay timeout should be cleared. Why? A search request should only be started after i havent presse a key for $delay ms. If i got it right you set a timeout for EACH keydown and don't clear the old timeout.
2. If a AJAX request (or generally speaking a source lookup) is ongoing and I change the state of the input (e.g. by pressing a key). The request should be cancelled immediately and not after $delay
Attachments (0)
Change History (4)
Changed December 01, 2011 09:49AM UTC by comment:1
Changed December 01, 2011 01:25PM UTC by comment:3
component: | ui.core → ui.autocomplete |
---|---|
summary: | Race condition in autocomplete → Autocomplete: Race condition with autoFocus |
Changed February 11, 2012 06:04PM UTC by comment:4
_comment0: | #7555 was closed with a milestone of 1.9, so testing against 1.8.16 is not valid. The fix landed on October 12 and 1.9m5 was released in September, so testing against 1.9m6 is not valid. If you're still seeing a problem in master, let us know. → 1328983803248052 |
---|---|
resolution: | → invalid |
status: | new → closed |
#7555 was closed with a milestone of 1.9, so testing against 1.8.16 is not valid. The fix landed on October 12 and 1.9m6 was released in September, so testing against 1.9m6 is not valid. If you're still seeing a problem in master, let us know.
Formatting "bug", once again:
Legend: 1 = first async thread, 2 = 2nd async thread
This happens sequentially as listed:
Where is my 'a'??