Closed Bug 364325 Opened 16 years ago Closed 16 years ago

History search shows the results in wrong (reverse) sort order


(Firefox :: Bookmarks & History, defect)

Not set



Firefox 3 alpha1


(Reporter: ria.klaassen, Assigned: moco)



(Keywords: regression)


(1 file)

Steps to reproduce:

- start a new profile with blank history
- open the sidebar, set "View" to "By Last Visited"
- visit
- visit
- verify that bug 362003 is on top in the history sidebar (that's correct)
- now do a history search for "history.dat" in the sidebar

Result: both entries change position: the last visited address is no longer on top (like in Firefox 2.0)
thanks for catching this.

here's what I did wrong:

106   // if there is a search string, root the places tree into
107   // the history root (sorted by SORT_BY_TITLE_ASCENDING)
108   // otherwise, root the tree based on gHistoryGrouping
109   if (aSearchString)
110     placeURI += "&sort=" + NHQO.SORT_BY_TITLE_ASCENDING;

I need to sort based on gHistoryGrouping, so in the case when we are grouped by last visted, I need to sort by:

Assignee: nobody → sspitzer
Target Milestone: --- → Firefox 3 alpha1
OS: Windows XP → All
Summary: History search shows the results in reverse order → History search shows the results in wrong order
*** Bug 326705 has been marked as a duplicate of this bug. ***
Re-changing summary for leaving words out makes it very difficult for me to find.
Summary: History search shows the results in wrong order → History search shows the results in wrong (reverse) order
I dropped 'reverse' from the summary because it's only a coincidental artifact of the comment 0 testcase that the titles of the visited pages sort alphabetically in the opposite order from their last visit time.
Summary: History search shows the results in wrong (reverse) order → History search shows the results in wrong (reverse) sort order
or, rather, the same, but, you get the idea :)
Attached patch fixSplinter Review
fix this bug, and remove my optimization for " /* don't re-root if the placeURI has not changed */ ", as when you deleted the search string, we would not re-filter/re-group the results.
Attachment #249818 - Flags: review?(mano)
Comment on attachment 249818 [details] [diff] [review]

Attachment #249818 - Flags: review?(mano) → review+

Checking in history-panel.js;
/cvsroot/mozilla/browser/components/places/content/history-panel.js,v  <--  hist
new revision: 1.4; previous revision: 1.3

thanks for the review, asaf.
Closed: 16 years ago
Resolution: --- → FIXED
This is fixed indeed but now it shows a temporary hang of more than a minute when I search for the word "window" in a places.sqlite file of 2.8 MB. 
ria, is that reproducible?  which history view?  (last visited, date / site, etc..)
Component: History → Places
QA Contact: history → places
Tested again but now I still see a large places.sqlite.file but no history in the sidebar anymore. But when I search for the word "window", I see a hang although the search results are in the right order now.
I have browser.history_expire_days set to 900 days.
The test works fine when I run the same profile in a branch build.
Yesterday I saw the imported history in my sidebar but now only the today's history again.
If you want I can send you the profile for testing purposes (it's not very privacy sensitive but not in a way I can attach it here for there are hidden mail data). 
Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061229 Minefield/3.0a2pre
Depends on: 333965
ria, spun off your hang issue to bug #365992.  if you have a profile that I can use, that would be great.
The problem (when having a search in history, results are not sort per the selected order) still exists in v 3.0.3/win.
And apparently on Mac (bug 434284) and linux (bug 392497).

Detailed version string:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008092417 Firefox/3.0.3

Please reopen.
And fix ;-)
Duplicate of this bug: 392497
Duplicate of this bug: 434284
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.