389491 - have url bar autocomplete do a case-insensitive search against both url and title with results ordered by a combination of last visited and visit count

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

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

have url bar autocomplete search against both url and title, doing a case insensitive LIKE search, ordered by last visited first.

details coming

Comment 1

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

challenges:

a)  chunking

In order to not freeze the ui when searching over the entire places db as you type (see bug #373256), I'm searching by chunks.

We chunk by visit date, starting at today and working backwards.

Upon hitting the max results (see bug #388090, the goal is to avoid a scroll bar, with the last item being "Show all results..."), we'll stop searching.

This means when you type something like "g" in the url bar, we'll quickly be able to find the max results (and then stop, which is important).
this is important because with the current autocomplete code / widget, you can search asynchronous, but you can't return results incrementally.  
I'll discuss with Neil Deakin and other toolkit folks in a spin off bug.

as you continue to type, we'll start our chunk again at today.  (later, we might decide to optimize by scanning our previous results before resuming chunking
but this hasn't proved necessary yet in my local testing.)

as long as the chunk size is reasonable, we will not block the ui when typing,searching even if there are no matches.

I'm ordering the search results by visit date (most recent at the top) and chunking in the same order, so I can stop when we hit the max.
additionaly, this makes it so when you click on "Show all results..." we can create a full query that matches the results in the url bar.

(but in the history autocomplete code I need to remove duplicates because when chunking by date ranges, you can get results you already have.)

b)  sqlite's LIKE has problems with non-ascii and case sensitivity:

The LIKE operator is not case sensitive and will match upper case characters on one side against lower case characters on the other. (A bug: SQLite only understands upper/lower case for 7-bit Latin characters. Hence the LIKE operator is case sensitive for 8-bit iso8859 characters or UTF-8 characters. For example, the expression 'a' LIKE 'A' is TRUE but 'æ' LIKE 'Æ' is FALSE.).

but there is an extenstion that can help.  See http://www.mail-archive.com/[e-mail]/msg26040.html

http://www.sqlite.org/cvstrac/fileview?f=sqlite/ext/icu/README.txt&v=1.2

(I will spin this out for past m7.)

c) edge cases

because the autocomplete currently can't incrementally show results, if you have a large history and you query for something that only appears once, as a very old visit, it will appear that you have no matches (as chunking is going on the background.)  if you wait, you'll get a drop down with that one result, but only after chunking through the entire db.

a user would see an increase in the CPU usage while we chunk through the places db.  (but at least you can continue to type your url manually.)

I'll log a spin off bug about having some feedback to indicate that we're searching.

Comment 2

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

Attachment: draft patch, v1

Comment 3

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

playing with this patch, what would really make this better is incremental results in autocomplete.  

that would help solve this scenario:

I go to the same page over and over (mail.mozilla.com).  I know the title or url contains zimbra, so I type zim in my urlbar.

we'll find it, and mail.mozilla/zimbra and mail.mozilla.com/zimbra/mail, but because only those three unique urls in my history, we'll have to chunk search the entire places db before returning the three resutls (because my current patch stops at 10.)

note, mconnor and beltzner don't like the "show all results..." / limiting results (see bug #388090 comment #11), so I assume they don't like me limiting the results to 10 here.

incremental autocomplete results would also address that, although I think there is something to be said to limiting the results to 10 and not having a scroll bar at all.  (as jesse points out, IE/Win shows 8 without a scrollbar).  but I'll defer to mconnor and beltzner.

the problems I'm describing only show up with large histories (a places.sqlite with 40,000 moz_historyvisits from ispiked is what I'm playing with locally.)

Comment 4

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

Attachment: updated patch, with incremental results (and no limit)

Comment 5

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

Attachment: updated patch

Comment 6

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

with my last patch, the thing I need to fix first is:

if you do something to close the results popup, I need to stop the search.

other comments / todo items:

a) the nsAutoCompleteController.cpp change is bug #389593

b) * XXX explain.... the algorithm

c) for the typed query

turn the hard coded AUTOCOMPLETE_MAX_PER_TYPED 100 into a pref? 

(this can be slow over a large history, see bug #386168 for comments and a suggestion from marco to keep create an index p.typed)

d) 

+// XXX what are good values?
+#define AUTOCOMPLETE_SEARCH_RANGE (USECS_PER_DAY)
+#define AUTOCOMPLETE_SEARCH_TIMEOUT 300

make these tuneable prefs, for experimentation.

e)

// don't rebuild this hash every time XXX todo

f)

// XXX ensure mCurrentEndTime is not zero. make it:
// min(mCurrentEndTime, now - mExpiredDays * USECS_PER_DAY)

g)

log bug on i18n sqlite issue (with a test case)

h)

keep parts of the existing algorithm:  within a chunk of results, boost bookmarks over non bookmarks, typed url over clicked links, shorter paths over longer paths.

Comment 7

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

Attachment: stop searching, properly escape searches

Comment 8

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

Attachment: stop searching (even if the popup is closed when we change inputs)

Comment 9

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

Attachment: updated snapshot

Comment 10

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

i)

another i18n issue:

visit

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aunofficial&hs=9DD&q=%C4%97&btnG=Search

in the url bar you will see:

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aunofficial&hs=9DD&q=ė&btnG=Search

but we won't find "q=ė" but you will find "q=%C4%97"

Note a search for ė will work, as the title of "http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aunofficial&hs=9DD&q=ė&btnG=Search" is "ė - Google Search"

Comment 11

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

moving to m8.

Comment 12

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

Not blocking, but definitely wanted and feels like the right approach.

Comment 13

[Jesse Ruderman]

> Upon hitting the max results (see bug #388090, the goal is to avoid a scroll
> bar, with the last item being "Show all results..."), we'll stop searching.

This will remind users of Spotlight in Mac OS X 10.4, which is terrible in both usability and performance :(

> this is important because with the current autocomplete code / widget, you can
> search asynchronous, but you can't return results incrementally.  

Designing UI based on limitations of the current code is usually a bad idea.  That said, now that 10 results are visible, I'm not sure which UI is better (scrollbar or "Show all results...").

Comment 14

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

jesse, it might not be clear from the comments in this bug but:

I don't stop on max results anymore, and I'm not appending "Show all results".  I am searching (chunk at a time).  I figured out how result results incrementally.

I hope to land this patch in early in m8, but if you'd like to apply it and try it out (or check it out over my shoulder), please do!

Comment 15

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

> I hope to land this patch in early in m8

correction:  I hope to land a cleaned up version of this patch in early m8.

Comment 16

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

in nsNavHistory::CreateAutoCompleteQuery()

instead of selecting MAX(visit_date) that is not used in results or in autocomplete and then order by 5, maybe could be better to directly do ORDER BY MAX(visit_date) so it's not in the results and sqlite results array should have little less memory usage. This could be done anywhere where ordering on a not needed (in results) field.

also you don't need the order by in the internal query if you don't limit the internal query 

hwv, doing some testing on large history i don't see the advantage of using an internal subquery if then you don't limit on it. In autocompletetyped the internal subquery is limited so it returns less results to the external one and it performs faster. Here it is not limited, i get faster results using the plain query:

SELECT h.url, h.title, f.url, b.id
FROM moz_places h
JOIN moz_historyvisits v ON h.id = v.place_id
LEFT OUTER JOIN moz_bookmarks b ON b.fk = h.id
LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id
WHERE
visit_date >= ?1 AND visit_date <= ?2
AND typed = 1 and (h.title LIKE ?3 ESCAPE '/' OR h.url LIKE ?4 ESCAPE '/')
GROUP BY h.id
ORDER BY MAX(v.visit_date) DESC

Comment 17

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

resuming working on this for M8.  

Will start with Marco's comment #16 and address some other open todo items.

Comment 18

[Brett Wilson]

I don't understand this. It looks like you are killing all hope of using any indices using this command. The previous statement was designed very carefully to use the indices, so the results appear quickly. How can you get reasonable performance, especially with 180 days of history?

Comment 19

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

shawn, check out EscapeForSQLiteLIKE() in the latest patch for your LIKE query in download manager,  and then do:  "...WHERE x LIKE ?1 ESCAPE '/'"

Comment 20

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

> I don't understand this.

the goal of this patch is to make it so I can type anything in the url bar (url fragment or title fragment, and soon META DESCRIPTION fragments, and hopefully more) and find results.  

the existing code was tuned for urls autocomplete only.

> How can you get reasonable performance, especially with 180 days of history?

this is a good point.  we can't query all your places or we'll block the UI.  instead, I do an incremental search, right now a day at a time (but that may change), and return results as they come in.  this does not block the UI.

if you type a bit more, we start over.  (so it is like the google search suggest).

I'm currently sorting results by last visited (newest first).  I have a feeling that we'll be tuning that slightly (within the "day" result chunk) to take into account visit count, bookmarked status, and other factors.

This is something I hope to clean up and land in early M8 so that people can play with it, but if you have a tree, consider trying it out now.

Comment 21

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

Attachment: patch for review

Comment 22

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

> Will start with Marco's comment #16 and address some other open todo items.

Marco was correct, and his query is faster (by my tests) and cleaner.  Thank you Marco!

Comment 23

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

Comment on attachment 275154 [details] [diff] [review]
patch for review

clearing review request, until I figure this out:

when chunk searching, and you click in the url bar (which closes the results popdown), we need to stop searching.  otherwise, the url bar results popdown will come down again.

Comment 24

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

Attachment: patch

this patch includes changes to:

1) stop the asynch search if you click (mousedown) in the url bar.  previously, that would cause us to rollup the results, but with async searches, we also need to stop the search so we don't open the results again

2) stop the async search if you hit the escape key.

3) stop the async search if you hit the context menu key.

for the toolkit changes, I think Neil, Mano or Gavin should also review.

Comment 25

[Dietrich Ayala (:dietrich)]

Comment on attachment 275193 [details] [diff] [review]
patch

haven't done a full code review yet, but after testing the patch out, here are a couple of interaction-y things that need to be fixed, as well as a bug:

- the popup is *really* flickery and jumpy as i'm typing into the location bar. i'm not sure if it's showing/hiding, or just re-populating, but it needs to be much smoother.

- after removing all characters from the location bar, the popup is still showing. it should be hidden.

- after typing in a string that matches only a couple of entries in history, the popup continues to fill (i can see the scrollbar growing) with empty entries.

Comment 26

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

dietrich, thanks for testing it out.

#1)  not seeing that one on windows xp.

#2)  not seeting that one on windows xp.

#3)  I saw that with early versions of the patch, but I addressed it with the toolkit changes.  have you fully rebuilt everything?  

I'll fully rebuild on windows xp to double check, but I'll also try on mac.

Comment 27

[Brett Wilson]

I would just be surprised if it can be made to work as smoothly as the old one, but if it works fast enough, I'm not going to argue.

Comment 28

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

Attachment: same patch (but updated to the trunk)

Comment 29

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

dietrich:  I've applied the patch to my mac build, fully clobbered and rebuilt, and:

1)  for one profile, I see the flickering.  investigating.

2)  I haven't gotten stuck with the empty popup

3)  I haven't gotten stuck with empty entries

I'll investigate the flickery issue and report back.  Can you try a full clobber / rebuild to see if issue #2 and #3 are still a problem?

Comment 30

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

Attachment: updated patch, search the previous results before starting the db search

Comment 31

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

Attachment: updated patch

if our search is able to re-use the previous results, resume searching in the database where the previous search left off.

Comment 32

[Dietrich Ayala (:dietrich)]

hey seth, latest patch fixes post-load flickering completely on mac. after the popup shows, i can type characters forward and delete them, with zero flickering. thanks much for following this up.

now the only flickering i see when the popup first loads. this is the incremental flicker i described on irc:

when the popup first appears, it has 4 rows. it flickers, and then the other 6 rows appear (completing the visible 10 rows). it then flickers again corresponding to each chunk of results.

i don't think we should block on the initial flicker, it can be addressed in betas.

Comment 33

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

Attachment: updated patch

this patch includes two small changes for "poor man's frecency":

1) ordering by visit count within a chunk of results 
2) a fix to the comment about the algorithm

Comment 34

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

Attachment: updated patch, chunk size of 4 days

per irc discussion with dietrich:

now that we have poor man's frecency, it makes sense to increase the chunk size to 4 days, so that friday's visits impact monday's autocomplete results.

Comment 35

[Dietrich Ayala (:dietrich)]

Comment on attachment 275511 [details] [diff] [review]
updated patch

review comments about the previous patch. hopefully these still apply.

>  * The current algorithm searches history from now backwards to the oldest
>  * visit in chunks of time (AUTOCOMPLETE_SEARCH_CHUNK).  We currently
>  * do "contains" searches on the URL and title.  results are ordered
>  * by last visited so that as results come in, they don't jump
>  * around on the user (and we can always simply append them.)
>  */

s/contains/LIKE/ ?

>-
> void EscapeForSQLiteLIKE(const nsAString& aInput, nsString& aOutput);
> 

this seems like it would be generally useful. should it be in mozStorageHelper.h, or somewhere in storage?

>   nsCString sql = NS_LITERAL_CSTRING(
>     "SELECT h.url, h.title, f.url, b.id "
>     "FROM moz_places h "
>     "JOIN moz_historyvisits v ON h.id = v.place_id "
>     "LEFT OUTER JOIN moz_bookmarks b ON b.fk = h.id "
>     "LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id "
>     "WHERE visit_date >= ?1 AND visit_date <= ?2 AND hidden <> 1 AND "
>     " visit_type <> 0 AND visit_type <> 4 AND ");
> 
>   if (mAutoCompleteOnlyTyped)
>     sql  = NS_LITERAL_CSTRING("typed = 1 AND ");
> 
>   sql  = NS_LITERAL_CSTRING(
>     "(h.title LIKE ?3 ESCAPE '/' OR h.url LIKE ?3 ESCAPE '/') "
>     "GROUP BY h.id ORDER BY MAX(v.visit_date) DESC ");
> 

please prefix all column names with their table alias to avoid ambiguity. right now it's mixed (sometimes prefixed, sometimes not).

> static const PRInt64 USECS_PER_DAY = LL_INIT(20, 500654080);
> // search in day chunks.  too big, and the UI will be unresponsive
> // as we will be off searching the database.
> // too short, and because of AUTOCOMPLETE_SEARCH_TIMEOUT
> // results won't come back in fast enough to feel snappy.
> #define AUTOCOMPLETE_SEARCH_CHUNK (USECS_PER_DAY)
> // wait this many milliseconds between searches
> // too short, and the UI will be unresponsive
> // as we will be off searching the database.
> // too big, and results won't come back in fast enough to feel snappy.
> #define AUTOCOMPLETE_SEARCH_TIMEOUT 100

please add an empty line before starting a comment, for readability

>  
>   // if doing a full search, and we're not done searching, 
>   // but adjust our end time and search the next earlier
>   // chunk of time

s/but//

>   // determine if we can start by searching through the previous search results
>   // if we can't, we need to reset mCurrentChunkEndTime and mCurrentOldestVisit
>   // if we can, we will search through our current results and then resume 
>   // using the previous mCurrentChunkEndTime and mCurrentOldestVisit

super-nit: some periods here would make this easier to read


>   nsCString sql = NS_LITERAL_CSTRING(
>     "SELECT h.url, h.title, f.url, b.id, MAX(v.visit_date) "
>     "FROM moz_places h "
>     "LEFT OUTER JOIN moz_bookmarks b ON b.fk = h.id "
>     "LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id "
>     "JOIN moz_historyvisits v ON h.id = v.place_id WHERE (h.id IN "
>     "(SELECT DISTINCT h.id from moz_historyvisits, moz_places h WHERE "
>     "place_id = h.id AND h.typed = 1 AND visit_type <> 0 AND visit_type <> 4 "
>     "ORDER BY visit_date DESC LIMIT ");

please prefix column names with table alias. place_id in particular should be disambiguated, since so many tables use that column name.

>     nsCAutoString faviconSpec;
>     faviconService->GetFaviconSpecForIconString(
>       NS_ConvertUTF16toUTF8(entryImage), faviconSpec);

need to check result value here?

> 
> // nsNavHistory::AutoCompleteFullHistorySearch
> //
>-//    A brute-force search of the entire history. This matches the given input
>-//    with every possible history entry, and sorts them by likelihood.
> //    Search history for a given range of time.
> //
>-//    This may be slow for people on slow computers with large histories.
> 
> nsresult
>-nsNavHistory::AutoCompleteFullHistorySearch(const nsAString& aSearchString,
>-                                            nsIAutoCompleteSimpleResult* aResult)
> nsNavHistory::AutoCompleteFullHistorySearch()
> {

the comment for this is odd, given that there's no given range of time. maybe some text about the date-based chunking here?

>   // Determine the result of the search
>   while (NS_SUCCEEDED(mDBAutoCompleteQuery->ExecuteStep(&hasMore)) && hasMore) {
>     nsAutoString entryURL, entryTitle, entryImage;
>     mDBAutoCompleteQuery->GetString(0, entryURL);
>     mDBAutoCompleteQuery->GetString(1, entryTitle);
>     mDBAutoCompleteQuery->GetString(2, entryImage);
>     PRInt64 bookmarkId = 0;
>     mDBAutoCompleteQuery->GetInt64(3, &bookmarkId);

can you either use these:

http://lxr.mozilla.org/mozilla/search?string=kAutoCompleteIndex

or remove them? (they're currently unused)

also, while you're in there can you remove this as well:

http://lxr.mozilla.org/mozilla/search?string=mDBFullAutoComplete

Comment 36

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

1)

> s/contains/LIKE/ ?

fixed.

2)

> > void EscapeForSQLiteLIKE(const nsAString& aInput, nsString& aOutput);

this seems like it would be generally useful. should it be in
mozStorageHelper.h, or somewhere in storage?

good point.  sdwilsh can use it for something he is working on (searching results in download manager).  moved (will seek review from sdwish)

3) 

> please prefix all column names with their table alias to avoid ambiguity. right
> now it's mixed (sometimes prefixed, sometimes not).

fixed, thanks.

4)

> please add an empty line before starting a comment, for readability

fixed, thanks.

5)

> >   // but adjust our end time and search the next earlier

s/but//

fixed, thanks.

6)

> super-nit: some periods here would make this easier to read

fixed, thanks.

7)

> please prefix column names with table alias. place_id in particular should be
> disambiguated, since so many tables use that column name.

fixed, thanks.

8)

> >     nsCAutoString faviconSpec;
> >     faviconService->GetFaviconSpecForIconString(
> >       NS_ConvertUTF16toUTF8(entryImage), faviconSpec);

> need to check result value here?

GetFaviconSpecForIconString() is a helper function that returns void.


9)

> the comment for this is odd, given that there's no given range of time. maybe
> some text about the date-based chunking here?

fixed, thanks.

10)


>can you either use these:
>
>http://lxr.mozilla.org/mozilla/search?string=kAutoCompleteIndex
>
>or remove them? (they're currently unused)

fixed, thanks.

11)

> also, while you're in there can you remove this as well:
> http://lxr.mozilla.org/mozilla/search?string=mDBFullAutoComplete

fixed, thanks.

Comment 37

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

Attachment: updated patch, per review comments from dietrich

Comment 38

[Dietrich Ayala (:dietrich)]

Comment on attachment 275852 [details]
updated patch, per review comments from dietrich


> 
>-// AutoCompleteResultComparator
>+// nsNavHistory::StartTimer

nit: s/StartTimer/StartAutoCompleteTimer/

r=me on the Places parts

Comment 39

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

Attachment: fixed the nit from dietrich, carrying over his r= for the places parts

Comment 40

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

Comment on attachment 275864 [details] [diff] [review]
fixed the nit from dietrich, carrying over his r= for the places parts

seeking additional review for the autocomplete changes (gavin/mano/neil/mconnor?) and the storage changes (sdwilsh)

Comment 41

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

Attachment: updated patch, storage changes have landed

carrying over dietrich review.  here's the updated patch to refect changes made to mozilla/storage.  

awaiting additional review from gavin on the toolkit parts.

Comment 42

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

Attachment: updated patch, includes fix for bug #392141

Comment 43

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

Attachment: updated patch, includes fix for bug #392141

Comment 44

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

Attachment: updated patch, includes fix for bug #392141 (excludes the fix for bug #389593)

Comment 45

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

Comment on attachment 277185 [details] [diff] [review]
updated patch, includes fix for bug #392141 (excludes the fix for bug #389593)

carrying over review from dietrich

Comment 46

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

fixed

Checking in browser/themes/pinstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v  <--  browser.cs
s
new revision: 1.64; previous revision: 1.63
done
Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v  <--  browser.cs
s
new revision: 1.75; previous revision: 1.74
done
Checking in toolkit/components/places/src/nsNavHistory.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v  <--  nsNavHis
tory.cpp
new revision: 1.156; previous revision: 1.155
done
Checking in toolkit/components/places/src/nsNavHistory.h;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v  <--  nsNavHisto
ry.h
new revision: 1.92; previous revision: 1.91
done
Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v  <
--  nsNavHistoryAutoComplete.cpp
new revision: 1.16; previous revision: 1.15
done

Comment 48

[en_keksiny_muuta]

How can i turn off searching autocomplete results by title?

Comment 49

[Nickolay_Ponomarev]

Why was the boost for the URLs typed into the address bar removed?

Comment 50

[u88484]

This change is very, very annoying. See my screenshot for why.  I don't use bookmarks or keywords so I always type like moz, goog, neo to get mozillazine google or neowin.net to show up first on the list, I then hit the down arrow and then enter to load the site.  Now since this patch even if I type imageshack I have to scroll way down the list.  The list should not be sorted by subdomains or whatever it is called first or by title...who the hell knows the title of most pages anyways. 

http://img72.imageshack.us/img72/3307/26704949fl5.png

Also because of this patch typing in my case "ne" resulted in 7 entries before neowin (second part of the screenshot) when none of the entries before it even had "ne" in it. what the heck?

Comment 51

[u88484]

Forgot to also mention that if you (or at least for my setup) don't type very, very quickly its like firefox freezes after the first character since this "brilliant" change went in.

Comment 52

[Jesse Ruderman]

Kurt, you want bug 393678.

Comment 53

[Jonathan Baron]

(In reply to comment #50)
> This change is very, very annoying [..]....who the hell knows
> the title of most pages anyways.

I've also found it very difficult to figure out how this works.  For example, typing the letter s gives Google as the second entry.  I had to use View/Source to discover that this is probably the result of the S in "Mozilla Firefox Start Page."  Who knows?  So far as I can see, this is just noise (junk, garbage, irrelevant).  At least provide an option to turn it off.

Comment 54

[Mats Åhlberg]

This might be o good idea if it would not do a indiscriminate search
of the url..
I think it should just search from the beginning of the title and url.

so if i type

www.google
it would just look at the letters after www. if they match and not start at positions after google.com
all www. should be ignored.

any data outside of the server name should be ignored. eg www.google.com

hope i make sense here.

in the case of
http://www.sr.se/cgi-bin/gotland/program/index.asp?ProgramID=2407

it finds the go in gotland before google and that is just not right.

Comment 55

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

I think we need to weight more heavily against navigations that were directly done by the user, as opposed to overall visit count.  For instance, if I type in "bugz," my top result is:

https://bugzilla.mozilla.org/process_bug.cgi

I navigate to this URL a lot, but I have never fired up my browser and gone there.  It's too bad we can't tell the difference between events like the user typing in a location, or clicking on a bookmark, so we could value user initiated navigations higher.

Comment 56

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

Nickolay wrote:

> Why was the boost for the URLs typed into the address bar removed?

Alex wrote:

> I think we need to weight more heavily against navigations that were directly
> done by the user, as opposed to overall visit count.

and Alex wrote:

> It's too bad we can't tell the difference between events like the user
> typing in a location, or clicking on a bookmark, so we could value user
> initiated navigations higher.

Actually, we can.  We know if a visit was typed, a link click, a bookmark click, or a few other transitions (embed, redirect).

I've started a new bug about using the visit_type instead of just the visit_count in our ac algorithm to address these comments from Nickolay and Alex.

See bug #394066

Comment 57

[Daniel Luz]

(In reply to comment #55)
> I think we need to weight more heavily against navigations that were directly
> done by the user, as opposed to overall visit count.  For instance, if I type
> in "bugz," my top result is:
> 
> https://bugzilla.mozilla.org/process_bug.cgi

This one particularly (and I believe *lots* of others, actually) can be easily solved: do not show POST requests in the address bar (or better: do not count POST requests as visits for the purposes of the URL bar). There's often very little you can do by GET-ing a POST url, so why show them at all?

Is there a bug for this? This is something I've been wishing to report for a long time, but I've never remembered it during some free time.

Comment 58

[Daniel Luz]

Sorry for the bugspam, but I found it: bug 94514. It even features a (five-year old) possible patch. Judging by its size, should still be something quite simple to solve today, I hope.

Comment 59

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

Daniel, thanks for the comments and for finding bug #94514.  I've morphed that bug into a places bug for firefox 3.

Comment 60

[Tracy Walker [:tracy]]

verified with - Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre

Comment 61

[Aaron Lawrence]

(In reply to comment #54)
> This might be o good idea if it would not do a indiscriminate search
> of the url..
> I think it should just search from the beginning of the title and url.
Sorry, but no.
That's what the old URL autocomplete search did, and it was FREQUENTLY useless. 
Reason: many useful sites use subdomains. Examples:
en.wikipedia.com
semiconductors.phillips.com

If I've visited wikipedia, I want "wik" to find it - how the heck would I remember to type "en.wik"?

Comment 62

[Mats Åhlberg]

What i tried to say is to reduce the searchpriority of the subdomains. First search priority should be main domain followed by page name. and we should really put a clean url at the top.

http://www.google.com
insted of
http://www.google.com/search?q=sfd&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Comment 63

[Caio Tiago Oliveira (asrail)]

How much the URLs are clean doesn't matter to me, but I agree that domains matching should got higher priority than subdomains matching and these should got higher priority than last token (page name without extensionor folder name if any and the page is index or welcome), that got higher priority than page title matching, which got higher priority than arbitrary text matching.

Comment 64

[Aaron Lawrence]

Ah, I agree about the clean URL Mats... this is another thing that makes the autocomplete useless currently because it suggests these ridiculous form submission URLs, which can only be used after tediously editing them - pointless. I think there might be another bug about that.

For subdomains, do you mean that if I have visited www.wikipedia.org and also en.wikipedia.org, it should find the first one earlier? But how could it know that without making big assumptions about URLs?

Comment 66

[d]

please add an option to FF3 to use autocompletion only by the URL beginning.

Comment 67

[Jesse Ruderman]

("d" has filed bug 422610 for that.)

Comment 68

[Tracy Walker [:tracy]]

litmus test https://litmus.mozilla.org/show_test.cgi?id=8713