I found it kind of hard to summarise this; Usually when I enter a url, I'll type the first few letters (usually three or four) - the problem I have is that history matches usually show up after two letters, then all disappear on the third. If I type in a fourth, they reappear. So for example, I want to go to facebook - I type 'fac' in the awesomebar. It pops up on the 2nd letter, but I type too fast to stop at that point and I type the 'c', and all my results disappear. If I type the 'e', they reappear, and similarly if I backspace. I've experienced this for ages, I'm not sure how long this bug has been floating about - it's in current release and in Nightly though, and I experience it on both Windows and Linux.

I'm sure there's an old bug about this, since it's clearly a longstanding issue.

I can reproduce this quite reliably in my profile, so can help provide some debugging info if needed. n?'ing unfocused, as requested.

As Marco says, I think this is a fairly well understood issue - we kick off searches after every keystroke (off a timer), and don't always properly re-use past results. I couldn't find another bug about this, though...

I think most of this is related to Adaptive results, they can appear in the middle of results just by adding one letter, but could not be there with 2 or 4 letters, exactly cause they adapt to the relation between typed chars and the final result. I think the visual effect could be reduced by introducing some sort of buffering so that we stop opening and closing the popup and replacing the result everytime. We should instead insert results dynamically and maybe also have some animation for popup sizing. We could even investigate matching adaptive results even before the full string has been typed, but that would require quite some brainstorming to not perturb the good mixup of results we have to today.

for example in this case "goo" would have one more result mixed up with others: go -> no adaptive entry goo -> has adaptive entry goog -> no adaptive entry

(Forgot to clear this after the past couple of comments. I'd assumed this wasn't understood when Chris mentioned he saw it so regularly.)

Oh, and buffering is one thing we've discussed recently as a wish-list item for the controller.

I think this is duplication of Bug 1047613 which has a patch.

(In reply to Alice0775 White from comment #8) > I think this is duplication of Bug 1047613 which has a patch. I'm not so sure the situation described in bug 1047613 is the same as this one, but once that gets marked as fixed I'll see if I can reproduce.

not enough info to reproduce