Copy of bug 659437 comment 2: (In reply to bug 659437 comment #1) > As warned against in bug 566489 comment 13, I seem to get different > behavior depending how quickly I hit Enter after typing. > > With arewefastyet.com in my history, I sometimes get a google search for > 'arewe' (if I hit enter quickly) and sometimes get arewefastyet.com (if I'm > not fast yet). I strongly advocate for fixing this. It is ironic that a UX-efficiency win also costs the user in efficiency, because now the user has to wait for an async operation to get consistent results. We really should create a synchronous fast path for the inline autocompletion as described in bug 566489 comment 19.

Trying to better understand this bug report. Is the issue that the text is showing that it's going to autocomplete to arewefastyet.com, and it doesn't, or that the text does not autocomplete fast enough?

It doesn't autocomplete fast enough.

OK, so here's what Chrome does: - Create an in-memory database - Fill it with all URLs that have been typed at least once - Search on that database synchronously on the main thread. This leaves a good dilemma for us. If we follow this exactly, limi's use case on the original bug 566489 comment will no longer apply, because we only fill with URLs that have been already typed (and his example of cnn.com/blahblahblah wouldn't have been typed). But filling with all URLs would likely take up too much memory. limi, thoughts? (PS I've been spending today thinking up a strategy for this bug and may be on the verge of having one)

I have a similar problem when using keywords - I have 'bz' hooked up to bugzil.la, but occasionally I get a google search for 'bz 123456' instead.

The way Home Dash did it was in-JS-memory lookup of various top sites that are frequently visited. If you're going to the same page by typing "m<enter>", it'll end up in the synchronous lookup. If you don't frequently go to "z<enter>", it's not too unreasonable that you don't really know where that's going to go anyway as you don't go there often.

Oh, I guess one slight difference in Home Dash is that it remembered the full url and not just the domain, so for me, when I typed "f<enter>" in Home Dash, it would always take me to http://forums.mozillazine.org/viewforum.php?f=23 as opposed to http://forums.mozillazine.org/

I've also experienced what Josh reported in comment #4.

(In reply to comment #3) > OK, so here's what Chrome does: > - Create an in-memory database > - Fill it with all URLs that have been typed at least once > - Search on that database synchronously on the main thread. > > This leaves a good dilemma for us. If we follow this exactly, limi's use > case on the original bug 566489 comment will no longer apply, because we > only fill with URLs that have been already typed (and his example of > cnn.com/blahblahblah wouldn't have been typed). But filling with all URLs > would likely take up too much memory. My approach would be slightly different — but let me know if there are issues with doing it like this, as I'm not a Proper Computer Scientist. ;) I'd like to keep the ability to autofill even things you haven't typed manually, but it's also more important for domains than for the rest of the URL. So how about this: 1. We keep the top-level domains in an in-memory database (which should be a much smaller set of data than all URLs), and complete using this for the initial completion 2. Once we reach the fragment completion (ie. the rest of the URL after the domain), we can either: a) decide to use the existing approach, as it doesn't need to be as fast — or; b) pre-populate the rest of the result set once the domain has scoped it down, since it's likely to be very few URLs within a given domain.

with the feature pulled we don't need to track for Firefox 6.

After extensive debugging, my local set of patches implements 1) and 2a). Uploads should come in a few days.

In bug 566489, for the vast majority of cases, we have fixed this by doing this synchronously, so I'm closing this bug.