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.
Regression? (sounds like bug 52419.)
Confirmed, 2001-07-20-03 on Windows 98 SE. (I use Group-By: None).
This is global history.
*** 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...
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 20011205.
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.
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 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 (*).
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 timeframe?
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));
Created attachment 101699 [details] [diff] [review] Patch as per comment 22 Wow, it works! Thank you so much Oswald!!! Keep up a good job!
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.
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.
Created attachment 103658 [details] [diff] [review] Modified patch as per comment 27
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?
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.
Comment on attachment 103664 [details] [diff] [review] Modified modified patch sr=bzbarsky
Comment on attachment 103664 [details] [diff] [review] Modified modified patch a=roc+moz for trunk
Verified vixed 2002102208/NT4. Somebody please verify on Linux / Mac?
It is wonderful to finally have this fixed. Thanks to all you guys!