Closed Bug 414254 Opened 14 years ago Closed 14 years ago

Wait a while before searching in the location bar

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta3

People

(Reporter: Mardak, Assigned: Mardak)

References

Details

(Keywords: perf)

Attachments

(1 file, 1 obsolete file)

865 bytes, patch
Mardak
: review+
Details | Diff | Splinter Review
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.
Attached patch v1 (obsolete) — Splinter Review
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.
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #299613 - Flags: review?(seth)
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!
Flags: blocking-firefox3?
Keywords: perf
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!
Attachment #299613 - Flags: review?(seth)
Attachment #299613 - Flags: review?(gavin.sharp)
Attachment #299613 - Flags: review+
>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.
Attachment #299613 - Flags: review?(gavin.sharp) → review+
Attachment #299613 - Flags: approval1.9?
(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
Attachment #299613 - Flags: approval1.9? → approval1.9+
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
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M11
Attached patch v1.1Splinter Review
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
Attachment #299613 - Attachment is obsolete: true
Attachment #299948 - Flags: review+
Flags: blocking-firefox3? → blocking-firefox3+
VERIFIED
via comment 12
Status: RESOLVED → VERIFIED
Blocks: 430461
You need to log in before you can comment on or make changes to this bug.