Closed
Bug 91417
Opened 23 years ago
Closed 21 years ago
history sort order should be persisted
Categories
(Core Graveyard :: History: Global, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.2final
People
(Reporter: bruppel1, Assigned: bugzilla)
References
Details
(Whiteboard: verifyme)
Attachments
(1 file, 2 obsolete files)
571 bytes,
patch
|
roc
:
review+
bzbarsky
:
superreview+
roc
:
approval+
|
Details | Diff | Splinter Review |
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 2•23 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
Comment 3•23 years ago
|
||
This is global history.
Assignee: radha → alecf
Component: History: Session → History: Global
Reporter | ||
Comment 5•22 years ago
|
||
91414 is for the sidebar. shouldn't it be separate?
Comment 6•22 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•22 years ago
|
Target Milestone: --- → mozilla0.9.9
Reporter | ||
Comment 7•22 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•22 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•22 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•22 years ago
|
||
Posted bug 109374 on the "group by" not persisted issue.
Comment 11•22 years ago
|
||
just wanted to note that I see this problem on OpenVMS as well, build from 20011205.
Comment 12•22 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•22 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Comment 13•22 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•22 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 (*).
Comment 15•22 years ago
|
||
The bug still exists in Build 2002051006 (aka RC2).
Comment 16•22 years ago
|
||
Can confirm comment #14 with RC2 on PC/WinMe
Comment 17•22 years ago
|
||
Build ID 2002060305, the bug still there...
Comment 18•22 years ago
|
||
*** Bug 148961 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
*** Bug 149865 has been marked as a duplicate of this bug. ***
Comment 20•22 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•21 years ago
|
||
Can someone update us on why this bug is so difficult to fix? What is the timeframe?
Comment 22•21 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•21 years ago
|
||
Wow, it works! Thank you so much Oswald!!! Keep up a good job!
Comment 24•21 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•21 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 26•21 years ago
|
||
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•21 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•21 years ago
|
||
Attachment #101699 -
Attachment is obsolete: true
![]() |
||
Comment 29•21 years ago
|
||
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•21 years ago
|
||
Merp... Patchmaker put the resulting diff into the wrong directory. My apologies, here's the correct one.
Attachment #103658 -
Attachment is obsolete: true
![]() |
||
Comment 31•21 years ago
|
||
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+
![]() |
||
Comment 33•21 years ago
|
||
checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 34•21 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•21 years ago
|
||
It is wonderful to finally have this fixed. Thanks to all you guys!
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•