history sort order should be persisted

RESOLVED FIXED in mozilla1.2final

Status

()

Core
History: Global
RESOLVED FIXED
17 years ago
15 years ago

People

(Reporter: Ben Ruppel, Assigned: Blake Ross)

Tracking

Trunk
mozilla1.2final
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: verifyme)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Regression? (sounds like bug 52419.)

Comment 2

17 years ago
Confirmed, 2001-07-20-03 on Windows 98 SE. (I use Group-By: None).
Assignee: asa → radha
Status: UNCONFIRMED → NEW
Component: Browser-General → History: Session
Ever confirmed: true
QA Contact: doronr → claudius
This is global history. 
Assignee: radha → alecf
Component: History: Session → History: Global

Comment 4

17 years ago
*** Bug 91414 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

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

Comment 6

17 years ago
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
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.9
(Reporter)

Comment 7

16 years ago
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

16 years ago
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?
(Reporter)

Comment 9

16 years ago
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?
(Reporter)

Comment 10

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

Comment 11

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

Comment 12

16 years ago
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.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla1.0.1

Comment 13

16 years ago
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

16 years ago
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 (*).

Updated

16 years ago
Blocks: 138000

Updated

16 years ago
No longer blocks: 138000

Updated

16 years ago
Blocks: 138000
No longer blocks: 138000

Comment 15

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

Comment 16

16 years ago
Can confirm comment #14 with RC2 on PC/WinMe

Comment 17

16 years ago
Build ID 2002060305, the bug still there...

Comment 18

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

Comment 19

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

Comment 20

16 years ago
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

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

Comment 22

15 years ago
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

15 years ago
Created attachment 101699 [details] [diff] [review]
Patch as per comment 22

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

Updated

15 years ago
Keywords: patch, review
Whiteboard: patch-in-hand, need-review

Comment 24

15 years ago
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

15 years ago
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 27

15 years ago
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+

Comment 28

15 years ago
Created attachment 103658 [details] [diff] [review]
Modified patch as per comment 27
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+

Comment 30

15 years ago
Created attachment 103664 [details] [diff] [review]
Modified modified patch

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

sr=bzbarsky
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 34

15 years ago
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

Comment 35

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

Updated

15 years ago
Whiteboard: patch-in-hand → verifyme
You need to log in before you can comment on or make changes to this bug.