Closed Bug 486978 Opened 16 years ago Closed 16 years ago

History in library is no longer sorted by visit date but by name

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: luke.iliffe, Assigned: mak)

References

Details

(Keywords: regression, verified1.9.1)

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090405 Minefield/3.6a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090405 Minefield/3.6a1pre Since bug 422163 landed when opening up the history (History | Show All History, then opening one of the new date range containers the display history entries are sorted by name rather than by visit date (descending). Reproducible: Always Steps to Reproduce: 1. Open minefield with a profile that contains some browsing history 2. Open library, (History | Show All History) 3. Expand a date container that contains history (either clicking the container in the left panel or double clicking the container in the right panel Actual Results: Note how history entries are sorted by name. Expected Results: History entries sorted by visit date (descending) It is easier to see visit date if you add that column (Views | Show Columns | Visit Date). This seems to be a regression from bug 422163 as it was working in the 2009-04-02 nightly build.
Blocks: 422163
Keywords: regression
Version: unspecified → Trunk
Confirmed, setting to New. Changing the sort with View->Sort - say setting it to 'unsorted' is not preserved when changing date folders, or when closing/reopening History, the sort order reverts to 'By name' No errors in Console2 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090405 Minefield/3.6a1pre Firefox/3.0.7 ID:20090405234649
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
i'm not completely sure this is an actual regression, but it's for sure a change in the interaction. Before you were going to the Library, click on History, (wait a bunch of seconds :(), then scroll down history from newest to oldest. Now you go to Library, click on History, choose the container that you think has the page you are looking for, (wait far fewer time), then scroll pages by name. Changing the engraved sorting order of splitted containers could also involve changing how the sidebar works (bug 487021). I'm fine to change both to default sorting by newer to older (rather than alphabetical), but that change should be approved/required by ux team. Or we could change how these queries work, and apply the sort= option to nodes inside the containers, ignoring it for containers itselves. I'll try to investigate this way.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attached patch patch v1.0 (obsolete) (deleted) — Splinter Review
btw, the sortingmode was currently ignored for date queries, so there should be no drawback in using it.
Attachment #371455 - Flags: review?(dietrich)
Flags: in-testsuite?
Hardware: x86 → All
Comment on attachment 371455 [details] [diff] [review] patch v1.0 > PRUint16 resultType = > mResultType == nsINavHistoryQueryOptions::RESULTS_AS_DATE_QUERY ? >- nsINavHistoryQueryOptions::RESULTS_AS_URI : >- nsINavHistoryQueryOptions::RESULTS_AS_SITE_QUERY; >+ nsINavHistoryQueryOptions::RESULTS_AS_URI : >+ nsINavHistoryQueryOptions::RESULTS_AS_SITE_QUERY; > indent is still one space off
Attachment #371455 - Flags: review?(dietrich) → review+
(In reply to comment #4) > (From update of attachment 371455 [details] [diff] [review]) > > > PRUint16 resultType = > > mResultType == nsINavHistoryQueryOptions::RESULTS_AS_DATE_QUERY ? > >- nsINavHistoryQueryOptions::RESULTS_AS_URI : > >- nsINavHistoryQueryOptions::RESULTS_AS_SITE_QUERY; > >+ nsINavHistoryQueryOptions::RESULTS_AS_URI : > >+ nsINavHistoryQueryOptions::RESULTS_AS_SITE_QUERY; > > > > indent is still one space off you won't believe me but that was wanted, but probably we format those as a ? b : c; rather than a ? b : c;
Attached patch patch v1.1 (deleted) — Splinter Review
Attachment #371455 - Attachment is obsolete: true
Target Milestone: --- → Firefox 3.6a1
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Blocks: 474287
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre
Status: RESOLVED → VERIFIED
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. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: