Closed Bug 470544 Opened 13 years ago Closed 13 years ago

places history sorting doesn't work right in grouped view

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: juergenherz, Assigned: neil)

References

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081220 SeaMonkey/2.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081220 SeaMonkey/2.0a3pre

There seems to be a bug in the sorting when the list is grouped - or I just don't understand the philosophy.

I'd expect the entries within a group (within the same site or day) be in the order indicated by View/Sort. But it only is directly after sorting until closing and reopening history or changing the grouping.

Reproducible: Always

Steps to Reproduce:
1. Ungrouped view, sorted by last visited.
2. Group view by day
3. Order is unsorted

4. Sort by last visited again
5. Close and reopen history window
3. Order is unsorted
Blocks: 468809
Version: unspecified → Trunk
This looks like a places bug. We can't afford to sort the view after every expand, but we could work around the problem with reopening or regrouping by manually sorting afterwards. Thoughts?
Status: UNCONFIRMED → NEW
Component: UI Design → Places
Ever confirmed: true
Product: SeaMonkey → Toolkit
QA Contact: ui-design → places
Attached patch Proposed patch (obsolete) — Splinter Review
I've had to work around Places in two parts, because grouped views are forcibly sorted by title. In the case of opening the window or changing the view, the solution is to enforce the sort after performing the initial query. (Any persisted expanded containers are also sorted recursively.) In the case of clicking on a twisty, I override the default options on the node to be opened, so that it sorts the way we want it to. This has no effect when closing or reopening a twisty but I don't have an easy way to detect the latter case.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #356418 - Flags: review?(iann_bugzilla)
i think in toolkit we could take a sorting for grouped results, ignore it in the first level containers, but use it when sorting site containers), the same for all groupings, ignore the sorting at containers level but forward it to inner containers. if the sorting is not specified then go for the actual default (sort by title ascending). So you could simply change the sidebar query specifying your preferred sorting for inner queries.
As yet I still haven't been able to persuade Places to inherit the sorting mode, but this patch works in more cases than the previous one did.
Attachment #356418 - Attachment is obsolete: true
Attachment #356498 - Flags: review?(iann_bugzilla)
Attachment #356418 - Flags: review?(iann_bugzilla)
Comment on attachment 356498 [details] [diff] [review]
Better workaround

Is there a bug to fix in toolkit, if so is it worth mentioning in the comments in the suite code?
Attachment #356498 - Flags: review?(iann_bugzilla) → review+
Pushed changeset e7bdae0af1a7 to comm-central.

I filed bug 474287 on Places.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Component: Places → UI Design
Product: Toolkit → SeaMonkey
QA Contact: places → ui-design
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.