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

VERIFIED FIXED in Firefox 3 alpha8

Status

()

Firefox
Location Bar
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
Firefox 3 alpha8
Points:
---
Dependency tree / graph
Bug Flags:
wanted-firefox3 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [places-ui])

Attachments

(1 attachment, 18 obsolete attachments)

49.60 KB, patch
(not reading, please use seth@sspitzer.org instead)
: review+
Details | Diff | Splinter Review
have url bar autocomplete search against both url and title, doing a case insensitive LIKE search, ordered by last visited first.

details coming
Depends on: 387714, 389492
Blocks: 373256, 383672
Depends on: 388090
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/sqlite-users@sqlite.org/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.
Status: NEW → ASSIGNED
Created attachment 273712 [details] [diff] [review]
draft patch, v1
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.)
Created attachment 273834 [details] [diff] [review]
updated patch, with incremental results (and no limit)
Attachment #273712 - Attachment is obsolete: true
Depends on: 389593
Created attachment 273881 [details] [diff] [review]
updated patch
Attachment #273834 - Attachment is obsolete: true
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.
Created attachment 273887 [details] [diff] [review]
stop searching, properly escape searches
Attachment #273881 - Attachment is obsolete: true
Created attachment 273889 [details] [diff] [review]
stop searching (even if the popup is closed when we change inputs)
Attachment #273887 - Attachment is obsolete: true
Created attachment 273912 [details] [diff] [review]
updated snapshot
Attachment #273889 - Attachment is obsolete: true
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"
moving to m8.
Flags: blocking-firefox3?
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Not blocking, but definitely wanted and feels like the right approach.
Flags: blocking-firefox3?
Whiteboard: [wanted-firefox3]
Blocks: 390404
Blocks: 387718

Comment 13

10 years ago
> 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...").
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!
> 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.
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


resuming working on this for M8.  

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

Comment 18

10 years ago
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?
shawn, check out EscapeForSQLiteLIKE() in the latest patch for your LIKE query in download manager,  and then do:  "...WHERE x LIKE ?1 ESCAPE '/'"
> 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.
Created attachment 275154 [details] [diff] [review]
patch for review
Attachment #273912 - Attachment is obsolete: true
Attachment #275154 - Flags: review?(dietrich)
> 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 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.
Attachment #275154 - Flags: review?(dietrich)
Created attachment 275193 [details] [diff] [review]
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.
Attachment #275193 - Flags: review?(dietrich)
Attachment #275154 - Attachment is obsolete: true
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.
Attachment #275193 - Flags: review?(dietrich)
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

10 years ago
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.
Created attachment 275451 [details] [diff] [review]
same patch (but updated to the trunk)
Attachment #275193 - Attachment is obsolete: true
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?
Created attachment 275499 [details] [diff] [review]
updated patch, search the previous results before starting the db search
Attachment #275451 - Attachment is obsolete: true
Created attachment 275511 [details] [diff] [review]
updated patch

if our search is able to re-use the previous results, resume searching in the database where the previous search left off.
Attachment #275499 - Attachment is obsolete: true
Attachment #275511 - Flags: review?(dietrich)
Blocks: 391156
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.
Blocks: 391175
Created attachment 275808 [details] [diff] [review]
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
Attachment #275511 - Attachment is obsolete: true
Attachment #275808 - Flags: review?
Attachment #275511 - Flags: review?(dietrich)
Created attachment 275812 [details] [diff] [review]
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.
Attachment #275808 - Attachment is obsolete: true
Attachment #275812 - Flags: review?(dietrich)
Attachment #275808 - Flags: review?
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
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.
Created attachment 275852 [details]
updated patch, per review comments from dietrich
Attachment #275812 - Attachment is obsolete: true
Attachment #275852 - Flags: review?(dietrich)
Attachment #275812 - Flags: review?(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
Attachment #275852 - Flags: review?(dietrich) → review+
Created attachment 275864 [details] [diff] [review]
fixed the nit from dietrich, carrying over his r= for the places parts
Attachment #275852 - Attachment is obsolete: true
Attachment #275864 - Flags: review+
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)
Attachment #275864 - Flags: review?
Whiteboard: [wanted-firefox3] → [wanted-firefox3][places-ui]
Flags: in-litmus?
Blocks: 391697
No longer blocks: 391156
Depends on: 391156
Blocks: 387714
No longer blocks: 391697
Depends on: 391697
No longer depends on: 387714
Created attachment 276202 [details] [diff] [review]
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.
Attachment #276202 - Flags: review+
Attachment #275864 - Attachment is obsolete: true
Attachment #275864 - Flags: review?
Blocks: 392141
Blocks: 392143
Blocks: 391887
Blocks: 392196
Created attachment 276742 [details] [diff] [review]
updated patch, includes fix for bug #392141
Attachment #276202 - Attachment is obsolete: true
Blocks: 385033
Created attachment 277182 [details] [diff] [review]
updated patch, includes fix for bug #392141
Attachment #276742 - Attachment is obsolete: true
Created attachment 277185 [details] [diff] [review]
updated patch, includes fix for bug #392141 (excludes the fix for bug #389593)
Attachment #277182 - Attachment is obsolete: true
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
Attachment #277185 - Flags: review+
Summary: have url bar autocomplete search against both url and title, doing a case insensitive LIKE search, ordered by last visited first → have url bar autocomplete do a case insensitive search against both url and title with results orderded by a combination of last visited and visit count
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Summary: have url bar autocomplete do a case insensitive search against both url and title with results orderded by a combination of last visited and visit count → 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
Duplicate of this bug: 384380
Blocks: 393570
Blocks: 393574
Blocks: 393578
Blocks: 373352
Blocks: 389273

Comment 48

10 years ago
How can i turn off searching autocomplete results by title?

Updated

10 years ago
Blocks: 393678

Comment 49

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

Updated

10 years ago
Depends on: 393705

Comment 50

10 years ago
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

10 years ago
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

10 years ago
Kurt, you want bug 393678.
No longer blocks: 393678
Depends on: 393678

Comment 53

10 years ago
(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

10 years ago
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.

Updated

10 years ago
Depends on: 393893

Updated

10 years ago
No longer depends on: 393893
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.

Blocks: 394038
Blocks: 393678
No longer depends on: 393678
Blocks: 394066
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

Updated

10 years ago
Depends on: 394079

Comment 57

10 years ago
(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

10 years ago
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.
Daniel, thanks for the comments and for finding bug #94514.  I've morphed that bug into a places bug for firefox 3.
Blocks: 94514
verified with - Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED

Updated

10 years ago
No longer depends on: 394079
Blocks: 405745

Updated

10 years ago
Depends on: 406358
Blocks: 294116

Comment 61

10 years ago
(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

10 years ago
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
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.
Summary: 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 → 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

Comment 64

10 years ago
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?

Updated

10 years ago
Duplicate of this bug: 410699
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3][places-ui] → [places-ui]

Comment 66

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

Comment 67

10 years ago
("d" has filed bug 422610 for that.)
litmus test https://litmus.mozilla.org/show_test.cgi?id=8713
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.