Closed
Bug 414287
Opened 17 years ago
Closed 17 years ago
Share search result processing logic as AutoCompleteProcessSearch
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
FIXED
Firefox 3 beta4
People
(Reporter: Mardak, Assigned: Mardak)
References
Details
(Keywords: perf, Whiteboard: [testcase in bug 416214 and bug 416211])
Attachments
(1 file, 5 obsolete files)
13.33 KB,
patch
|
Mardak
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
All the searches need to provide the same information to the nsIAutoCompleteResult, so we should make the code sharable to help reduce bugs.
Assignee | ||
Comment 1•17 years ago
|
||
The only user of aStyle right now is EmptyString(), but that'll be changed in a followup..
Assignee | ||
Comment 2•17 years ago
|
||
According to faaborg/beltzner, we should always favor the bookmark title over page title unless the search doesn't match the bookmark and does match the page title. Yay unit tests.
Attachment #299650 -
Attachment is obsolete: true
Attachment #299653 -
Flags: review?(seth)
Attachment #299650 -
Flags: review?(seth)
Assignee | ||
Comment 3•17 years ago
|
||
Don't use the bookmark title if it's empty (null in the db). That should be right sdwilsh? GetString( <null> ) will go through Variant magic and read out as EmptyString(), yeah?
I suppose you could unofficially review this refactoring change as well... :) ;)
(It passes the unit tests :))
Attachment #299653 -
Attachment is obsolete: true
Attachment #299849 -
Flags: review?(sdwilsh)
Attachment #299653 -
Flags: review?(seth)
Comment 4•17 years ago
|
||
Comment on attachment 299849 [details] [diff] [review]
v1.2
>+ PRBool useBookmarkTitle = itemId && !entryBookmarkTitle.IsEmpty() &&
So, if the column is null it will actually be a void string:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/storage/src/mozStorageStatement.cpp&rev=1.29#692
However, testing IsEmpty will still be true for a void string, so you are OK.
r=sdwilsh
Attachment #299849 -
Flags: review?(sdwilsh) → review+
Assignee | ||
Comment 5•17 years ago
|
||
Use tag search's process code because FullHistory filters results outside of SQL. Also, we can unescape like Fullhistory does.
Attachment #299849 -
Attachment is obsolete: true
Attachment #301078 -
Flags: review?
Assignee | ||
Updated•17 years ago
|
Blocks: awesomebar
Assignee | ||
Comment 6•17 years ago
|
||
Comment on attachment 301078 [details] [diff] [review]
v2
Refactoring to share this logic between tags and bug 395739 for adaptive.
Also adds the unescaping of the urls.
Attachment #301078 -
Flags: review? → review?(dietrich)
Assignee | ||
Comment 7•17 years ago
|
||
Comment on attachment 301078 [details] [diff] [review]
v2
New patch incoming that cleans up some stuff between the two search processing functions.
Attachment #301078 -
Flags: review?(dietrich)
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 8•17 years ago
|
||
Restore the meaning of "aHasMoreResults" and decide if we should chunk outside of FullHistory.
Get some perf win if we have enough results from either tags, so don't bother querying for more fullhistory searches.
We aren't filtering duplicates because we're entering the escaped url and checking with unescaped :( oops.
Unescape urls for tags.
Use bookmark title if we have it.
Get rid of unsigned/signed warning for nsStringArray.Count()
Attachment #301078 -
Attachment is obsolete: true
Attachment #301979 -
Flags: review?
Updated•17 years ago
|
Flags: wanted-firefox3+
Assignee | ||
Updated•17 years ago
|
Whiteboard: [testcase in bug 416214 and bug 416211]
Assignee | ||
Updated•17 years ago
|
Attachment #301979 -
Flags: review? → review?(dietrich)
Comment 9•17 years ago
|
||
Comment on attachment 301979 [details] [diff] [review]
v3
r=me for these changes.
re:
Mardak: dietrich: i was trying to see if i could/should share the logic between fullhistory and tags/adaptive.. but that seemed like it would either need a function pointer or extra parameters that conditionally decides to filter results, etc..
[8:40pm] Mardak: probably just better to leave them separate, so they're both faster?
should be easy enough to measure if adding a check for a bool param has a detectable perf impact.
Attachment #301979 -
Flags: review?(dietrich) → review+
Assignee | ||
Comment 10•17 years ago
|
||
I tried this out and there didn't seem to be any changes to the FullHistory processing time.
Basically v3 without the duplicate code for processing Tags. Also, there's an enum to choose which type of query processing to use. r? to make sure the style is acceptable.
Attachment #301979 -
Attachment is obsolete: true
Attachment #302674 -
Flags: review?(dietrich)
Assignee | ||
Comment 11•17 years ago
|
||
Comment on attachment 302674 [details] [diff] [review]
v4
r=dietrich over irc
<dietrich> Mardak_: looks fine
This will help fix a couple bugs like bug 416211 and bug 416214 and helps implement bug 395739.
I'll land the testcase in bug 416214 with this patch.
Attachment #302674 -
Flags: review?(dietrich)
Attachment #302674 -
Flags: review+
Attachment #302674 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #302674 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 12•17 years ago
|
||
Checking in toolkit/components/places/src/nsNavHistory.h;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v <-- nsNavHistory.h
new revision: 1.137; previous revision: 1.136
done
Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v <-- nsNavHistoryAutoComplete.cpp
new revision: 1.42; previous revision: 1.41
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta4
You need to log in
before you can comment on or make changes to this bug.
Description
•