For fast typers, we don't need to search every single character if they're coming in groups of characters (probably 2-3 letters for the initial word). For slower typers.. the time for results to show up is probably smaller than the time for the user to type stuff anyway, so not too bad.

How about 150ms? It's shorter than search's 250ms.. but I tried it for a little bit and 250ms is definitely noticable delay.. for me.

note: 250 ms not a suggestion for the url bar, it was just what the search bar was doing. (crude math: 50 words per minute, using PARIS as the word length, 250 chars per minute / 60 seconds, round down to 4 chars per second, or one char per 250 ms. see also http://en.wikipedia.org/wiki/Words_per_minute) I think we want some sort of timeout, but I'm not sure if 150ms is correct, but it seems reasonable. faaborg/beltzner always seem to know about this sort of thing, so let's seek their opinion. I think this blocks fx 3. one request: please run this review by gavin (or mconnor), instead of me. super kudos to mossop for pointing out this issue in bug #414229!

Comment on attachment 299613 [details] [diff] [review] v1 r=sspitzer, but again I'm not sure the right timeout here, but 150 ms seems reasonable. we need to to goldilocks this value. too small, and our searches slow down typing. too big and you will have to wait a beat after you stop typing to get results. we want it just right. this patch + your limit max results should do good things for mossop. if possible, can we have him try each independently? also, seeking additional review from gavin, who has forgetten more about the browser than I ever learned!

>faaborg/beltzner always seem to know about this sort of thing, so let's seek >their opinion. I think the lag time for the search bar was set to be higher because it had more to do with blasting too many searches at google, than what would be noticeable by the user. In terms of setting a reaction time, events that occur within 50-200ms will appear to be an instantaneous direct result of the user's action. Going beyond 200ms will produce a noticeable lag between the user's action and the computer's response. The range is due to some people literally being able to process perceptual information faster, how focused the user is, what environment they are in, etc. In practice, going for 100ms is a good compromise. For instance, a movie at 10fps will still produce perceptual fusion and won't appear to be a slideshow of separate images. What we should set our lag time to should also take into account how long it takes to complete the search and display updated results on the screen. For instance, if this only takes an average of 20ms, then we can pause for 80ms to see if any other characters come in before we fire off the updated search, and still get the results on screen in time to look instantaneous.

Comment on attachment 299613 [details] [diff] [review] v1 (In reply to comment #4) > >faaborg/beltzner always seem to know about this sort of thing, so let's seek > >their opinion. > > I think the lag time for the search bar was set to be higher because it had > more to do with blasting too many searches at google, than what would be > noticeable by the user. You're right, the 250ms timeout was added mostly to rate-limit the requests to the search suggest URIs, in bug 339441. It was rather arbitrary, but I haven't heard any complaints about laggy search suggest results - perhaps because people are used to having to wait for the remote requests for search URIs? I tried 250 with the location bar and it did indeed seem a bit laggy, compared to 150ms, so I think this is fine as a first shot.

(In reply to comment #5) > I haven't heard any complaints about laggy search suggest results In fact Sylvain filed bug 339441 because he was concerned about the opposite as a user - too many requests and too much bandwidth wasted by Firefox. He suggested 150ms there too, up from the default 50ms, but it looks like Joe went with 250ms.

gavin: Would the timeout cause problems if the user types in something and hits enter all before the timeout? Or would pushing enter cancel the timeout? Because if not, the drop down will appear even after we start loading a page.. ?

(In reply to comment #7) > gavin: Would the timeout cause problems if the user types in something and hits > enter all before the timeout? Shouldn't - there's code in nsAutocompleteController::HandleEnter that cancels the search timer.

Comment on attachment 299613 [details] [diff] [review] v1 a1.9+=damons

Checking in browser/base/content/browser.xul; /cvsroot/mozilla/browser/base/content/browser.xul,v <-- browser.xul new revision: 1.410; previous revision: 1.409 done

switched to 100ms per faaborg's comment on targeting 100ms. There's some time that it takes for results to get back, but at minimum the user is waiting 100ms. r=dietrich over irc

VERIFIED

via comment 12