392196 - url bar autocomplete ui progress

Status: VERIFIED DUPLICATE of bug 413497

(Firefox :: Address Bar, defect, P4)

Description

[(not reading, please use [e-mail] instead)]

url bar autocomplete ui progress

chatting with gavin and mconnor, once bug #389491 lands, here's a scenario to worry about:

1)  user has a giant history
2)  a long time ago, user went to a unique page like "http://www.gggfoobar.com"
3)  user types foobar in url bar
4)  we search, but since foobar is unique and the visit was a while ago, the result will not show up right away, but we are still searching

perhaps after a certain number of chunks, we should add a result: 
"Searching history..." so they know what is going on?  (should it even update every few ms?)

additionally, how does the user know when we are done searching?  Perhaps that is when we should append:  

"Search for foobar" (which maps to the google search)?

not sure what to do here yet.

Comment 1

[Dietrich Ayala (:dietrich)]

(In reply to comment #0)
> perhaps after a certain number of chunks, we should add a result: 
> "Searching history..." so they know what is going on?  (should it even update
> every few ms?)
> 

this sounds reasonable. we do this for livemarks that are in the process of loading.

Comment 2

[(not reading, please use [e-mail] instead)]

even with global frecency, this will still be an issue.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm generally for this, although the presentation would be tricky. I think I'd want it to appear in grey-italics as the last entry, so that as chunks get added, it's always bumped to the bottom, and eventually out of view so when it vanishes it's not that big a deal.

Alex also had an idea to replace the favicon with a throbber of some sort as a way of indicating progress, but not sure if we'll get that in time.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

an idea: the autocomplete is done in time chunks, since the real perf problem is searching the history, but before that we could already do 2 steps: a search in rev_host (on moz_places with visit_count > X for perf reason, done reversing the search term) and an adaptive learning search (Bug 395739), so the first results would be probably the most wanted (search in domain and search most used) and those steps *could* be fast enough. 
Then after those 2 steps add the history searches with the frecency algorithm to the required limit. This would clearly give more importance to the domain and less to the page title, but maybe to also fix a problem with people serching for domain starting with some letter the search could be like "moz" -> search in rev_host for "zom."

so:
1. search for domain starting with word in rev_host (or containing word)
2. search in adaptive learning
3. launch current frecency algorithm
Would this be possible?

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

we would like to create a two variable throbber, that has one animation for local activity, and another animation for network activity.  The first step is to move the throbber to the site button (bug 402968). 

Comment 6

[(not reading, please use [e-mail] instead)]

an idea from faaborg:

For the appending "Searching..." richlist item, make that items favicon be the busy throbber.

once we have a second throbber (for local activity), we could use it, but until then, use the existing throbber.

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

>once we have a second throbber (for local activity), we could use it, but until
>then, use the existing throbber.

Note that I was referring to the two state throbber being discussed, either way we only want to have one active throbber at a time between the site button and the results.

Comment 8

[Aru Sahni]

Has anyone else noticed a problem with the dropdown autocomplete list and the mouse?  That is, if I put the cursor over the area of the screen that will be taken up by the dropdown and have the field selected (control + l) and type one letter ('s' for example), the drop down will appear and the entry under the mouse cursor will be selected.

Is there some way to fix this and have it register the mouse cursor only if the cursor is moved while the dropdown is visible?

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified dup