424673 - Optimize AwesomeBar for correcting typos or removing terms that caused no results

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Ed Lee :Mardak]

Often times search results drop to 0 because you typo a word or you're trying to figure out which search terms to use. E.g., "bugz aweso type" 0 results -> "bugz aweso" 12 results -> "bugz aweso typing" 4 results.

Instead of starting a search from the very beginning each time something is deleted, we can keep track of a set of results for the delete case.

Comment 1

[Ed Lee :Mardak]

Attachment: v1

We can cache certain search results for use when deleting characters from the search term. We need to save the urls, search term, and current chunk position.

This patch chooses when to save search results based on if we have more results than the current cache. So this works for partial searches as well.

E.g., chunk0 finds 5, chunk1 finds 5 more. We first cache the 5 results from chunk0 then cache 10 results after chunk1.

If the user searches for something that restricts results.. e.g., 3 results from chunk0, and 0 from chunk1, we keep our 10 cached results.

Additionally, if we keep hitting max results, we take the most recent results. So searching for "p" matches everything and isn't useful for caching. If you search for "plan" and get 12 max results, we replace the 12 results we found when matching "p".

Comment 2

[Ed Lee :Mardak]

This can be tested by finding some pages that take some time to show up in history. In my case, I have "planet mozilla", "xul planet", and "planet jdk" in history, but xulplanet and planetjdk take some time to show up. (Perhaps increase your search timeout or decrease chunkSize.) Search for "planet m" then backtrack to "planet" and results should show up immediately.

Here's a build with this patch applied:

https://build.mozilla.org/tryserver-builds/2008-03-23_11:[e-mail]/

Bug 424673 - Optimize AwesomeBar for correcting typos or removing terms that caused no results
Bug 418257 - Show what part of which tags match for urlbar autocomplete
Bug 392143 - show keywords as url bar autocomplete choices
Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list
Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags
Bug 420437 - Search and emphasize quoted strings with spaces
Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions
Bug 423942 - "Clear List" in download manager should be "Clear Current List" during the search
Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter
Bug 414326 - Use DownloadUtils for software update downloads
Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)

Comment 3

[Robert [minotaur 11]]

The tryserver build (tested with linux and windows) doesn't always work as expected if i delete some characters. The steps below are the only way i found to reliable reproduce such a problem in a new profile.

STR:
1.Create 6 Bookmarks:
http://a1/, http://a2/, http://a3/, http://ab1/, http://ab2/, http://ab3/
2.Set browser.urlbar.search.chunkSize to 1 and
browser.urlbar.search.timeout to 1000
3.Click on the arrow on the right side of the location bar to open the location bar dropdown. Wait until all 6 results are displayed.
4.Click in the location bar
5.Type "a": 6 results
6.Type a additionally "b": 3 results
7.Delete the "b": 6 results (slow, like in step 5, should be almost instantly)

The example in the STR works if i skip step 3 in a session.

Comment 4

[Ed Lee :Mardak]

Comment on attachment 311271 [details] [diff] [review]
v1

Still not quite sure why it's slow after opening the list, but we can additionally optimize when going from "open dropdown" to typing because bug 411293 made them share the same code path. There's nothing special about dropdown search vs word search.

Comment 5

[Ed Lee :Mardak]

FYI, I do see the slow results only if I do step 3. Skipping step 3 makes it fast.

Comment 6

[Ed Lee :Mardak]

Oh duh. I cache results from the drop down because "it's like any other word search", but I only throw away cached results if the new term *doesn't* begin with the cached search.

Anything search will match a cached dropdown search.

However, I have CanUseSearch return false if the previous search was empty string. So when you type "a", it finds results, but not as many as the drop-down, so it doesn't get cached.

I'll get rid of that empty string check.

Comment 7

[Ed Lee :Mardak]

Attachment: v1.1

Set strings to void so that we can cache empty searches. :)

Comment 8

[Ed Lee :Mardak]

dwitte suggested something interesting.. which is how I had it implemented earlier accidentally ;) I didn't mCachedURLs.Clear() so it kept adding urls to the cache.

The problem is deciding when to reuse the cache. "m" "mo" "moz" "mozi" will all have results in the cache. I suppose we could always hit the cache every time because the cache just provides a list of urls to check first not necessarily using them.

Comment 9

[Ed Lee :Mardak]

Updated the build so it works with the drop down as well.

https://build.mozilla.org/tryserver-builds/2008-03-23_19:[e-mail]/

Bug 424673 - Optimize AwesomeBar for correcting typos or removing terms that caused no results
Bug 422277 - assertions in nsNavHistoryAutocomplete ("not a UTF8 string", etc.)
Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions
Bug 418257 - Show what part of which tags match for urlbar autocomplete
Bug 392143 - show keywords as url bar autocomplete choices
Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list
Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags
Bug 420437 - Search and emphasize quoted strings with spaces
Bug 423942 - "Clear List" in download manager should be "Clear Current List" during the search
Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)
Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter
Bug 414326 - Use DownloadUtils for software update downloads

Comment 10

[Ed Lee :Mardak]

Nevermind about caching everything. Looking at the pages out of order would potentially mess up the frecency order.

Comment 12

[Ed Lee :Mardak]

Comment on attachment 311304 [details] [diff] [review]
v1.1

unrequesting review for now as bug 429531 will cause changes to the logic needed here

Comment 13

[Dietrich Ayala (:dietrich)]

is this a problem still on current trunk still? how does async location bar affect this issue?

Comment 14

[Shawn Wilsher :sdwilsh]

(In reply to comment #13)
> is this a problem still on current trunk still? how does async location bar
> affect this issue?
The summary and initial comment don't quite line up, so I'm not sure what this is completely about at this point, but I think it's valid on trunk and with bug 455555.

Comment 15

[Ed Lee :Mardak]

This bug is about fixing typos and how we can reshow results faster when fixing the typo. Trunk optimizes for additional letters; this is optimizing for removing letters. Async doesn't do either right now.

Comment 16

[Tracy Walker [:tracy]]

removing in-litmus? until this is resolved, feel free to add it back at that
time.

Comment 17

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.