As far as I understand, currently autocomplete searches are re-executed each time the user types something into the location bar. Each time the search is run, the results are rebuilt from scratch. For responsiveness reasons the search is executed in small chunks of history. This leads to the following effect, which is mildly annoying: 1. Use a relatively long places DB (the one I'm currently seeing this bug on is ~3MB, couple months as far as I can tell; not the slowest PC here). 2. Find a place you've visited long ago (IIUC, chunking happens by visit_date, so this means the result will be found in the last chunk after a noticeable delay, but without locking up the browser) 3. Start typing its URL. Actual results: each time you type another letter the autocomplete results flicker - the autocomplete disappears, then re-appears with the same single result in it. Expected results: no visible changes while performing the chunked search, unless we know the results have changed. In case there are lots of matching results with different visit_date, you can see the autocomplete popup flickering, followed by the scrollbar flickering (since after the first chunk, there are few results, then there are more results), followed by gradual growth of the results list. Hard to explain, but it doesn't give very good impression of the app. Related: bug 413497 and bug 414513.

Tony: are we doing this sort of testing with large places DB files? We might want to generate one and do some testing. Neither mconnor nor I are seeing this (and we're not using the world's fastest machines atm) so I'm clearing the nom until we get more solid STR.

I'm not sure why solid steps to repro are needed here, given that the underlying issue is clear. (I haven't looked at the code, but judging from the symptoms, we do rebuild the autocomplete list from scratch each time - that's the issue.) So it's a matter of using "right" search terms on a right DB for the user to see this. Anyway, I'll try to create a testcase places DB for this bug and get someone to repro this. Not soon, but it's on my to do list.

Bug 422177 made it in for beta5 which should fix this problem by starting from where the last search left off.