91417 - history sort order should be persisted

Status: RESOLVED FIXED

(Core Graveyard :: History: Global, defect)

Description

[Ben Ruppel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010718
BuildID:    2001071803

The history window does not remember its sort order.  If you open history
(ctrl-H), close it, and open it again, the sort order you last set is not there
anymore.  It should be persisted.

Reproducible: Always
Steps to Reproduce:
1.Open the history window and click on a column to sort by that value
2.Close the history window and open it again

Actual Results:  The history will be sorted by title no matter what.

Expected Results:  The history window should remember and persist the sort order
that you last set.

Comment 1

[R.K.Aa.]

Regression? (sounds like bug 52419.)

Comment 2

[Mats Palmgren (inactive)]

Confirmed, 2001-07-20-03 on Windows 98 SE. (I use Group-By: None).

Comment 3

[Radha on family leave (not reading bugmail)]

This is global history. 

Comment 4

[Mike Potter]

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

Comment 5

[Ben Ruppel]

91414 is for the sidebar.  shouldn't it be separate?

Comment 6

[Alec Flett]

reassigning history bugs to new owner - send this bug back to me if it looks
like something I should fix (such as embedding-related architecture issues),
rather than the actual history owner...

Comment 7

[Ben Ruppel]

Hi, just recently history stopped remembering its "Group By" setting (the one
that lets you switch between the IE way and the old NS way of showing history).
 Is this related enough to this bug to go along under it?

Comment 8

[Claudius Gayle]

they are very similar but since that behvaior is a new regression it should be
written up separately. What build ID did you first notice this behavior in?

Comment 9

[Ben Ruppel]

It must have happened between November 1 and the 5th.  When I start up older
builds, they use my previous group selection (by none), so I think this is a
matter of recognizing the pref.  Want me to file the separate bug?

Comment 10

[Ben Ruppel]

Posted bug 109374 on the "group by" not persisted issue.

Comment 11

[Jay Farrell]

just wanted to note that I see this problem on OpenVMS as well, build from 
20011205.

Comment 12

[Hermann Voßeler]

just wanted to note some additional observations:
I use "Sorted by last visited" and "Z>A Order".
If you open histoy again, the latter setting is persisted
(Z>A Order), but the sort order changes back to "Sorted by location".

If you now click on a column (e.g. "Last Visited"), the arrow symbols 
do not match the aparent sort order any longer. After a rather long
intervall (5-10 seconds), the arrow symbols get updated.

Moreover, if I chose to display an additional column, e.g. "hostname"
and then close the history window, this setting is retained: next time
the "hostname" column showes up. BUT if I now set the sort order to
"hostname" and then close the window, next time I open the window 
the "hostname" column is hidden again.

I am using 0.9.7 (Build 2001122106) on Win NT 4
My history list usualy is very large, because I like it 
to remember the last 3 Months.

Comment 13

[Karl Guertin]

It appears to me that the sort order is being maintained by first visited
regardless of what sort order the user defines, it sorts by first visited from
the oldest to the newest.

Comment 14

[Wesha]

Now it seems to remember the order.... but it's really weird.
Build ID: 2002041711

Open history and switch it to "Netscape" mode (i.e. no folders)
Click on the column header to switch it to sort by "last visited" in descending
order.
Now close history window and open it again.

(*)
The arrow in the Last Visited header shows that the history is still sorted in
that order, but when you look closely, you see that it's actually not.
Click Last Visited header once more. The arrow disappears and ONLY THE FIRST
LINE of the history window changes.
Click again. This time it sorts properly in ascending order.
Click once more. This time it FINALLY sorts the way I wanted.

Close the window and you can repeat everything from the point marked (*).

Comment 15

[Wesha]

The bug still exists in Build 2002051006 (aka RC2).

Comment 16

[Claus Herwig]

Can confirm comment #14 with RC2 on PC/WinMe

Comment 17

[Wesha]

Build ID 2002060305, the bug still there...

Comment 18

[Robert Wall]

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

Comment 19

[Robert Wall]

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

Comment 20

[igch]

I'm not certain if this is the appropriate place to report this, but this
behaviour still manifests itself in Mozilla 1.1a (2002-06-11 04).

This issue should probably receive a bit higher priority than it seems to be
getting, as the History is a rather fundamental part of a browser and it irks me
that this hasn't been working properly for the longest time.  Unfortunately, I'm
not familiar with the inner workings of Mozilla, so I don't know if this should
be an "easy fix" or not.  I only hope that it is addressed promptly; it's rather
embaressing that the "finished version" of Mozilla was released with this defect.

In response to Comment #13 from Karl Guertin: It does seem that Mozilla shows
the History entries sorted by First Visited A > Z when the window opens, even
though every other sign points to being sorted by what the user intended (in my
case, Last Visited Z > A).

Comment 21

[Jay Davis]

Can someone update us on why this bug is so difficult to fix?  What is the
timeframe?

Comment 22

[Oswald Fischer]

Mozilla 1.0.1: 
I have find out that the behavior, describe in Comment #14, can solve with the
follow two lines on the End from the Function HistoryCommonInit() in history.js
contained in bin\chrome\comm.jar:

var xsort_column = find_sort_column();
SortInNewDirection(find_sort_direction(xsort_column));

Comment 23

[Wesha]

Attachment: Patch as per comment 22

Wow, it works! Thank you so much Oswald!!! Keep up a good job!

Comment 24

[moz]

The patch works for me in Mozilla 1.0.1, windows 2000, although maybe it's a very little slower?. Greetings to Oswald, congratulations!

Comment 25

[Jay Davis]

I have been complaining about this problem for ages now, on the forums mostly. 
Can someone tell me how to do a "patch" so that I can finally get this History
to work right?  Thanks.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 101699 [details] [diff] [review]
Patch as per comment 22

sr=bzbarsky; please mail ben, blake, or jag for a review.

Comment 27

[jag (Peter Annema)]

Comment on attachment 101699 [details] [diff] [review]
Patch as per comment 22

r=jag. I would like to see the sorting moved to before selecting the first
item, though. Right now it just happens to work since we're sorting within the
day grouping, so the first item will never move, but it just feels a little
unclean nonetheless.

Comment 28

[Wesha]

Attachment: Modified patch as per comment 27

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 103658 [details] [diff] [review]
Modified patch as per comment 27

This is identical to the other patch, no?  And does not in fact account for
comment 27?

Comment 30

[Wesha]

Attachment: Modified modified patch

Merp... Patchmaker put the resulting diff into the wrong directory. My
apologies, here's the correct one.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 103664 [details] [diff] [review]
Modified modified patch

sr=bzbarsky

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 103664 [details] [diff] [review]
Modified modified patch

a=roc+moz for trunk

Comment 33

[Boris Zbarsky [:bzbarsky]]

checked in.

Comment 34

[Wesha]

Verified vixed 2002102208/NT4. Somebody please verify on Linux / Mac?

Comment 35

[Jay Davis]

It is wonderful to finally have this fixed.  Thanks to all you guys!