If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Back/forward button history list is upside down -- Option to reverse (Firefox 3.0b4)




Toolbars and Customization
10 years ago
7 years ago


(Reporter: BvdG, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [CLOSEME 2011-2-25])



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

I find the order of the history list very unlogical. I read from top to bottom, expecting the first (earliest) thing to be on top and the last/latest on the bottom. What I see in the new keyhole back/forward history list is the other way around.

If there are somehow compelling reasons why it should be this way, can there at least be an option to change it around?

Reproducible: Always

Steps to Reproduce:
1. Create a history
2. Go back to middle of history
3. Click history list button (in the keyhole) or right-click on either back or forward button
4. and look at the order
Actual Results:  
Oldest page in history is at the bottom

Expected Results:  
Oldest page is at the top


10 years ago
Version: unspecified → Trunk


10 years ago
Severity: enhancement → normal

Comment 1

10 years ago
I agree.

This would make the back/forward history consistent with other use of the history in Firefox that use the "top=recent,bottom=old" idiom:
 - Awesome Bar;
 - History Sidebar (when viewing by date);
 - History menu;
 - History Places;
 - Download Manager


Comment 2

10 years ago
Wow, I must be tired... I misread the bug description. The list is already consistent with every other use of the history in Firefox.

Now I must admit that I do find this order confusing too. That's why I commented in the first place.

I will try to make an extension or a patch in order to reverse the list in order to have a little more feedback...

Again, sorry for the misunderstanding.

Comment 3

9 years ago
I would assume that the reason for having more recent items closer to the top of the list would be that one would go back to more recent pages more frequently than one would to older pages and that one would want the more frequently used recent pages closer to the button for faster browsing.

Comment 4

9 years ago
The option to reverse that list already exists for advanced users; just append the following lines to the userChrome.css file in your profile:

#back-forward-dropmarker > menupopup scrollbox > box {
   -moz-box-direction: reverse !important;

That's probably the best you'll get, though (besides maybe an extension).
Whiteboard: [wontfix?]

Comment 5

9 years ago
The userChrome workaround doesn't work for me....

@Joshua Dimmack: The way it works is that the immediately adjacent history items (the one just after and the one just before 'now' which is the most recent one) are right above and below the mouse pointer when the list appears. So your requirement is met irrespective of the order. For me it's just about changing the order.
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
Whiteboard: [wontfix?] → [CLOSEME 2011-2-25]

Comment 7

7 years ago
The issue still exists in the new 4.0 beta 11. See http://i54.tinypic.com/32znbxy.png where I used a fresh profile in safe mode -- the userChrome.css workaround is still not working.

If a preference could be added for this, I would still be in favor of it.
This bug has had the CLOSEME tag for several weeks and the date in the tag is
far gone. If the reporter can still see this issue, Please retest with Firefox
3.6.x or later and a new profile
(http://support.mozilla.com/kb/Managing+profiles). Then please remove the
closeme tag in the whiteboard, mark the bug against the proper version and
comment on the bug.
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.