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)
Firefox
Bookmarks & History
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)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•16 years ago
|
Comment 1•16 years ago
|
||
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
Updated•16 years ago
|
OS: Windows XP → All
Assignee | ||
Comment 2•16 years ago
|
||
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
Assignee | ||
Comment 3•16 years ago
|
||
btw, the sortingmode was currently ignored for date queries, so there should be no drawback in using it.
Attachment #371455 -
Flags: review?(dietrich)
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite?
Updated•16 years ago
|
Hardware: x86 → All
Comment 4•16 years ago
|
||
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+
Assignee | ||
Comment 5•16 years ago
|
||
(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;
Assignee | ||
Comment 6•16 years ago
|
||
Attachment #371455 -
Attachment is obsolete: true
Assignee | ||
Comment 7•16 years ago
|
||
Target Milestone: --- → Firefox 3.6a1
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Assignee | ||
Comment 8•16 years ago
|
||
pushed as a merged patch with bug 422163
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/969eb6567510
Keywords: fixed1.9.1
Comment 9•16 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
Comment 10•15 years ago
|
||
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.
Description
•