Closed Bug 91417 Opened 23 years ago Closed 21 years ago

history sort order should be persisted


(Core Graveyard :: History: Global, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: bruppel1, Assigned: bugzilla)



(Whiteboard: verifyme)


(1 file, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
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.
Regression? (sounds like bug 52419.)
Confirmed, 2001-07-20-03 on Windows 98 SE. (I use Group-By: None).
Assignee: asa → radha
Component: Browser-General → History: Session
Ever confirmed: true
QA Contact: doronr → claudius
This is global history. 
Assignee: radha → alecf
Component: History: Session → History: Global
*** Bug 91414 has been marked as a duplicate of this bug. ***
91414 is for the sidebar.  shouldn't it be separate?
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...
Assignee: alecf → blakeross
Target Milestone: --- → mozilla0.9.9
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?
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?
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?
Posted bug 109374 on the "group by" not persisted issue.
just wanted to note that I see this problem on OpenVMS as well, build from 
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.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
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.
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
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 (*).

Blocks: 138000
No longer blocks: 138000
Blocks: 138000
No longer blocks: 138000
The bug still exists in Build 2002051006 (aka RC2).
Can confirm comment #14 with RC2 on PC/WinMe
Build ID 2002060305, the bug still there...
*** Bug 148961 has been marked as a duplicate of this bug. ***
*** Bug 149865 has been marked as a duplicate of this bug. ***
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).
Can someone update us on why this bug is so difficult to fix?  What is the
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();
Attached patch Patch as per comment 22 (obsolete) — Splinter Review
Wow, it works! Thank you so much Oswald!!! Keep up a good job!
Keywords: patch, review
Whiteboard: patch-in-hand, need-review
The patch works for me in Mozilla 1.0.1, windows 2000, although maybe it's a very little slower?. Greetings to Oswald, congratulations!
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 on attachment 101699 [details] [diff] [review]
Patch as per comment 22

sr=bzbarsky; please mail ben, blake, or jag for a review.
Attachment #101699 - Flags: superreview+
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.
Attachment #101699 - Flags: review+
Attached patch Modified patch as per comment 27 (obsolete) — Splinter Review
Attachment #101699 - Attachment is obsolete: true
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?
Attachment #103658 - Flags: needs-work+
Merp... Patchmaker put the resulting diff into the wrong directory. My
apologies, here's the correct one.
Attachment #103658 - Attachment is obsolete: true
Comment on attachment 103664 [details] [diff] [review]
Modified modified patch

Attachment #103664 - Flags: superreview+
Comment on attachment 103664 [details] [diff] [review]
Modified modified patch

a=roc+moz for trunk
Attachment #103664 - Flags: review+
Attachment #103664 - Flags: approval+
checked in.
Closed: 21 years ago
Resolution: --- → FIXED
Verified vixed 2002102208/NT4. Somebody please verify on Linux / Mac?
Keywords: review
Whiteboard: patch-in-hand, need-review → patch-in-hand
Target Milestone: mozilla1.0.1 → mozilla1.2final
It is wonderful to finally have this fixed.  Thanks to all you guys!
Whiteboard: patch-in-hand → verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.