Closed
Bug 389491
Opened 17 years ago
Closed 17 years ago
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
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox 3 alpha8
People
(Reporter: moco, Assigned: moco)
References
Details
(Whiteboard: [places-ui])
Attachments
(1 file, 18 obsolete files)
(deleted),
patch
|
moco
:
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
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 1•17 years ago
|
||
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
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
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.)
Assignee | ||
Comment 4•17 years ago
|
||
Attachment #273712 -
Attachment is obsolete: true
Assignee | ||
Comment 5•17 years ago
|
||
Attachment #273834 -
Attachment is obsolete: true
Assignee | ||
Comment 6•17 years ago
|
||
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.
Assignee | ||
Comment 7•17 years ago
|
||
Attachment #273881 -
Attachment is obsolete: true
Assignee | ||
Comment 8•17 years ago
|
||
Attachment #273887 -
Attachment is obsolete: true
Assignee | ||
Comment 9•17 years ago
|
||
Attachment #273889 -
Attachment is obsolete: true
Assignee | ||
Comment 10•17 years ago
|
||
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"
Assignee | ||
Comment 11•17 years ago
|
||
moving to m8.
Flags: blocking-firefox3?
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Comment 12•17 years ago
|
||
Not blocking, but definitely wanted and feels like the right approach.
Flags: blocking-firefox3?
Whiteboard: [wanted-firefox3]
Comment 13•17 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...").
Assignee | ||
Comment 14•17 years ago
|
||
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!
Assignee | ||
Comment 15•17 years ago
|
||
> 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•17 years ago
|
||
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
Assignee | ||
Comment 17•17 years ago
|
||
resuming working on this for M8.
Will start with Marco's comment #16 and address some other open todo items.
Comment 18•17 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?
Assignee | ||
Comment 19•17 years ago
|
||
shawn, check out EscapeForSQLiteLIKE() in the latest patch for your LIKE query in download manager, and then do: "...WHERE x LIKE ?1 ESCAPE '/'"
Assignee | ||
Comment 20•17 years ago
|
||
> 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.
Assignee | ||
Comment 21•17 years ago
|
||
Attachment #273912 -
Attachment is obsolete: true
Attachment #275154 -
Flags: review?(dietrich)
Assignee | ||
Comment 22•17 years ago
|
||
> 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!
Assignee | ||
Comment 23•17 years ago
|
||
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)
Assignee | ||
Comment 24•17 years ago
|
||
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)
Assignee | ||
Updated•17 years ago
|
Attachment #275154 -
Attachment is obsolete: true
Comment 25•17 years ago
|
||
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)
Assignee | ||
Comment 26•17 years ago
|
||
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•17 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.
Assignee | ||
Comment 28•17 years ago
|
||
Attachment #275193 -
Attachment is obsolete: true
Assignee | ||
Comment 29•17 years ago
|
||
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?
Assignee | ||
Comment 30•17 years ago
|
||
Attachment #275451 -
Attachment is obsolete: true
Assignee | ||
Comment 31•17 years ago
|
||
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)
Comment 32•17 years ago
|
||
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.
Assignee | ||
Comment 33•17 years ago
|
||
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)
Assignee | ||
Comment 34•17 years ago
|
||
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 35•17 years ago
|
||
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
Assignee | ||
Comment 36•17 years ago
|
||
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.
Assignee | ||
Comment 37•17 years ago
|
||
Attachment #275812 -
Attachment is obsolete: true
Attachment #275852 -
Flags: review?(dietrich)
Attachment #275812 -
Flags: review?(dietrich)
Comment 38•17 years ago
|
||
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+
Assignee | ||
Comment 39•17 years ago
|
||
Attachment #275852 -
Attachment is obsolete: true
Attachment #275864 -
Flags: review+
Assignee | ||
Comment 40•17 years ago
|
||
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?
Updated•17 years ago
|
Whiteboard: [wanted-firefox3] → [wanted-firefox3][places-ui]
Updated•17 years ago
|
Flags: in-litmus?
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 41•17 years ago
|
||
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+
Assignee | ||
Updated•17 years ago
|
Attachment #275864 -
Attachment is obsolete: true
Attachment #275864 -
Flags: review?
Assignee | ||
Comment 42•17 years ago
|
||
Attachment #276202 -
Attachment is obsolete: true
Assignee | ||
Comment 43•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Attachment #276742 -
Attachment is obsolete: true
Assignee | ||
Comment 44•17 years ago
|
||
Attachment #277182 -
Attachment is obsolete: true
Assignee | ||
Comment 45•17 years ago
|
||
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+
Assignee | ||
Updated•17 years ago
|
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
Assignee | ||
Comment 46•17 years ago
|
||
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
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
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
Comment 48•17 years ago
|
||
How can i turn off searching autocomplete results by title?
Comment 49•17 years ago
|
||
Why was the boost for the URLs typed into the address bar removed?
Comment 50•17 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•17 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•17 years ago
|
||
Kurt, you want bug 393678.
Comment 53•17 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•17 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.
Comment 55•17 years ago
|
||
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.
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 56•17 years ago
|
||
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•17 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•17 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.
Assignee | ||
Comment 59•17 years ago
|
||
Daniel, thanks for the comments and for finding bug #94514. I've morphed that bug into a places bug for firefox 3.
Comment 60•17 years ago
|
||
verified with - Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Comment 61•17 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•17 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
Comment 63•17 years ago
|
||
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.
Updated•17 years ago
|
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•17 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•17 years ago
|
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3][places-ui] → [places-ui]
Comment 66•17 years ago
|
||
please add an option to FF3 to use autocompletion only by the URL beginning.
Comment 67•17 years ago
|
||
("d" has filed bug 422610 for that.)
Comment 68•15 years ago
|
||
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.
Description
•