120983 - Mixed up order of top groups in history window

Status: RESOLVED FIXED

(Core Graveyard :: History: Global, defect)

Description

[Daniel Bratell]

The history window has an strange order if the main groups:

SHOULD BE:
  Today
  Yesterday
  2 days ago
  ...
  6 days ago
  Older than 6 days

RIGHT NOW IT IS:
  Older than 6 days
  Yesterday
  2 days ago
  ...
  6 days ago
  Today


Probably a typo somewhere and a two line fix.

Comment 1

[André Dahlqvist]

I have the correct order with a CVS build from 2002-02-19-22 on Linux.

Daniel, what build are you using?

Comment 2

[André Dahlqvist]

Is it perhaps so that you accidentally clicked on the Location column so that
you have a down arrow on that one? If I do that I get the exact sort order you
describe. So this is probably WORKSFORME.

Comment 3

[Alec Flett]

I've noticed this too - random sort orders for the toplevel folders.

I think that it is actually sorted by the "find:" url that represents that
folder, or from a set of completely blank entries.

it's definitely not WORKSFORME though! we should not be randomly sorting when
you click on the Location column - it should be sorted in some predictable
manner (such as the default, chronological order)

Comment 4

[Daniel Bratell]

It's a home made build from yesterday on Windows 2k. I tried to look at the code
but the only thing I saw was that the top level nodes were added in the correct
order. After that something must be resorting them.

Comment 5

[Dan Tobias]

It's doing the exact same thing for me in Win98 build 2002012304.  I don't
recall ever seeing this problem before now, so either it just emerged recently
or it only happens after a fairly obscure series of events.

Comment 6

[Blake Ross]

Sorting by the name column actually works semi-correctly, even if it looks
weird.  It sorts by the title of the pages.  We could, alternatively, sort by
the toplevel folder names chronology...is that more useful?  Maybe, since you
could switch to flat view if you wanted title sorting.

Comment 7

[Pierre Chanial]

Nominating, since it is an in-da-face bug.

Comment 8

[Jaime Rodriguez, Jr.]

Can someone attach a screen shot, so we can see what this looks like?

Comment 9

[Pierre Chanial]

Attachment: screenshot showing the problem

The different pictures are obtained by clicking on the title header, from the
left to the right.
At least on linux, there is no other way that closing the history window to
restore the initial state. Sort order are looping 1-2-3-4-2-3-4-2-... etc

Comment 10

[Peter Trudelle]

nsbeta1+ per nav triage team, ->1.0

Comment 11

[Jaime Rodriguez, Jr.]

nsbeta1- per ADT triage.

Comment 12

[Asa Dotzler [:asa]]

*** Bug 180402 has been marked as a duplicate of this bug. ***

Comment 13

[Daniel Wang]

*** Bug 148539 has been marked as a duplicate of this bug. ***

Comment 14

[Vedran Miletic]

retargeting

Comment 15

[Alec Flett]

I think what's happening is that we're doing a GetTarget() on a find: url along
the #Location or #Name property, and we're getting garbage..

First we recognize find: urls and call GetTargets()
http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#1572

ah, I kind of see whats going on here. Instead of handling kNC_child the same as
IsFindResource(), a true result to IsFindResource() should be calling
GetTarget(aSource, kNC_child, ...) and then on THAT result, should be calling
GetTarget(result, aProperty, ...);

Comment 16

[timeless]

.

Comment 17

[[e-mail]]

Fixed by bug 382187.