Currently, the session history in the Back and Forward button menus is limited to 14 or 15 entries. If I need to back up more than 15 pages, I must repeatedly select entries from the Back button menu. The ability to go back up to 15 pages is much better than IE's limitation of 10. But if Mozilla could display the last 20 to 30 pages in the Back button menu, navigating many pages backwards (or forwards) would be much easier.

A simple work around: go to the last entry in the back button menu list. Click on the menu again, you will get 15 prior entries from that page. After that is loaded, click on the menu again, you get 15 more older entries. With 2 clicks you can go back to the 45th page back or forward.

Yes, I listed that workaround in my original bug report: "repeatedly select entries from the Back button menu". But it's annoying to do that. Mozilla is much less annoying than IE, but with even more entries on the Back button menu, it would be even less annoying still!

Marking RFE and marking NEW.. I think this should be a preference so that on low memory machines you wouldnt be burdened with the extra memory usage (small I know but could make a difference).

The change of the title and the comment about memory usage seem to indicate a misunderstanding of what the RFE is about. The Back Button does keep a history of more than 15 entries. It's just that the dropdown menu *displays* only 15 entries. That means that if you want to go back more than 15 pages, you have to repeatedly select the Back Button menu. All I'm asking for in this RFE is that the dropdown menu of the Back and Forward buttons display more of the entries that are already stored. Surely the tiny amount of memory required to draw a few (5 to 10) more menu items isn't a concern, is it?

This is again a browser feature. The requirement is pretty simple. The fix is also a one-liner in sessionHistoryUI.js. THe question is , do we want to do this? Browser team should decide that.

Can we just make this a pref exposed in Prefs > Navigator > History under the Session History titled box. The default value should be whatever it is now i.e. 15. This would be a good improvement. thanks, Vishy

20-30 entries is far too many to have in this quick access menu, and would probably end up slowing you down. I agree with Vishy that, if anything, it should be a pref. -> UI:DF for discussion

By the way, IE6 offers a new "History" choice (separator-delimited) at the bottom of the Back and Forward popup menus that, when clicked, opens the History explorer bar.

for my .02 i like this session history list unbounded. If I want to go 31 pages back in the history for 'this' window, then let me do it. NS 4.x did this nicely whereas IE 4.x didn't. It limited me to 15 and forced me to make 3 jumps back (15,15,1) to get all the way back. Who does it slow down? The user? - no. The browser? - if we can't draw a popup with 15 items as perceptively fast as 50 items then we suck and shouldn't be trying at all. </.02>

Really? 4.x for Windows limits it at 15 for me. And yes, I think it does slow down the user. How much longer do you think it'll take a user to find something in a menu of 50 items, compared to one of 30?

approx. 0 sec. :-) Seriously, when you're looking for an item that is listed sequentially in reverse order you start from the top and work your way down. So you get to the 30th item on the list at the same time. You're thinking of a situation where someone was scanning an entire list in a random fashion looking for an exact match. That would take longer but i don't think that's the case. Of course I could ask how long it takes to find the 16th item on a list that's only 15 items long. ps i just let browser buster go nuts in NS 4.76 and i now have a screenful of urls in my backbutton dropdown. Of course, this is on the mac...

I agree with Claudius...the limited back menu drives me crazy, and I find it no burden at all to look at a longer list because one starts at the top in any case. A user preference for this would be very nice.

I agree with Claudius. It makes no sense for the Back menu to be bounded when (for example) the Bookmarks menu is not. If you want to go back only five or six pages, you know that you need to go only five or six items down from the top of the menu; and that doesn't change, no matter how many items the menu contains. So any loss of time from being presented with a menu with a screenful of items in it, when you only want the 5th one, is trivial compared with the loss of time from wanting the 45th item down and having to go through three non-obvious menu selections to get there. A later enhancement could be to organize session history from days before the current one into submenus of the Back menu. That would help handle the edge case where someone uses the same browser window for all their browsing over several days. --> History: Session, polish based on Radha's comments.

Perhaps this could be done similar to the history of the URL bar? i.e. if there are "too many" items, display a scrollbar. (However, "too many" should be determined only by the height of the screen in both cases.)

I agree with Zack, the limit that is artifically put on this feature is annoying. An arrow put on the bottom of the back button window, so that you can scroll, would be a good improvement. By the way this annoyance is still present in Mozilla OSX 0.9.5 (Build ID: 201101516)

*** Bug 104854 has been marked as a duplicate of this bug. ***

This problem is still around in the build for OSX 0.9.7 . It appears that this has been around a long time and no one is paying any attention to it. It seems that this would be a simple fix since the links are available thru repeated back searches.

Still present in 1.1a builds. The bookmarks menu can be very long. Don't see why the same can't be true of the session history. The pages are already stored in memory, just displaying their names shouldn't be a big memory hit.

I've created two separate patches for this bug. The first one fixes the initial request to merely increase the number of items in the back menu session history to 25 items. The second patch is a try at making the length "unbounded," but in fact the maximum length is 100 entries, which is the maximum history currently stored. Note that this changes the maximum length of the back and forward buttons, the bottom of the Go menu, and the address bar history menu. Please try one or both of these patches -- if you don't know how, read about PatchMaker at http://www.gerv.net/software/patch-maker/build-mode.html -- and comment on how they work.

How do these patches interact with the "Number of pages in session history" preference (browser.sessionhistory.max_entries)? See also bug 104142.

This patch sets the maximum number of entries in the Back, Forward, and Go menus to 25, and leaves the URL Bar History menu with a maximum of 15 entries.

This patch allows the Back, Forward, and Go menus as long as the session history will allow. It also leaves the URL Bar History menu at a maximum of 15 items.

The latest "unbounded" patch allows the Back menu to be as long as the session history will allow: browser.sessionhistory.max_entries - 1. If bug 104142 is fixed, it will have a truly unbounded length.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/2002101815 (+ patches 101274, 101762, 103210) The latest patch is great. It is one of the most useful things I have in a while:-)) pi

I see a problem with the latest patch. I don't know if it is introduced by the patch or only becomes visible by it, it is not 100% reproducible, but happens pretty often. If you have a history in the Go menu which does not fit the screen (so you have those scrll arrows) and go back to some very early page, then click some link there, the go menu will no display anything anymore, but it has the right length. All tool bars become unusable at this time, so you have to close the particular window. Other windows are not affected. pi

We have a patch, this could easily be in 1.3b which would be a great improvement. pi

This is driving me nuts. This bug has a working patch for a very long time, but nobody cares to even review it:-( Removing dependency on bug 104142 since this patch works without that. pi

You do realize that radha was on vacation very recently, right? Like, if you would be patient and all, you might get a review.

I do not own the Back/Forward button UI. It belongs to the browser team. It is not clear to me if the browser team wants to implement this feature at all. Over to the browser team.

Over to XP Apss: GUI Features. Hopefully, it is correct there. pi

Bug 179117 is very similar to that one here. pi

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded I am successfully using this patch for many months now. It really deserves attention. pi

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded I am successfully using this patch for many months now. It really deserves attention. pi

Why isn't this patch being looked at? The Bounded Back Menu Session History is a continuing annoyance.

please seek review from someone in browser team. (sgehani, blaker or jaggernaut), as I do not own that code anymore.

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded Hm, timeless@bemail.org just changed it from jaggernaut (who did not respond for more than two months) to radha. OK, so thanks for your hint. pi

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded wow. has any work been done to measure exactly how much we're keeping around? Meaning that at least before if the history items held 5k of data each, then we'd max out at 500k. Now we just grow and grow infinitely. I don't like the idea. If we're going to do this I want to see some code to watch for the memory pressure notifications and knock off most of the session history if the notification fires. There needs to be some kind of automatic purging mechanism, we can't just let it be unbounded.

The "unbounded" patch shouldn't change how much memory is used to store the session history. It only alters the number of session history items that are displayed in the back, forward, or go menus. It's bug 104142 that will allow session history to grow beyond a fixed limit. It's really not correct to say that the patch allows the menu to be unbounded -- the bound is the number of session history items stored, which is bounded now but might be unbounded in the future.

Let me play with this. Without having seen it I'm afraid the dropdowns will become too big (as they fill the screen) and too busy for the unbounded case. I could see the benefit of increasing the value to 20 or 25, though.

.

jag, I don't understand your comment. As you can see in this screenshot the menu only extends to the bottom of the screen, it does not cover the whole screen, but allows to scroll up or down. pi

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded Again asking for sr, comment 40 explains the misunderstanding, which should make the concerns vanish. pi

man if you ask me that is a horrible user experience.

Hm, I see horrible user experience when I cannot go back a few pages. Why would it get worse when you can do it -- you don't need to. Especially with frame constructs, you may want to go to the last page before the frames begin which requires longer lists. pi

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded clearing this from my queue. I totally disagree with making this unbounded and so I won't sr= until I see module owner review.

I agree with Alec and Blake on this one. Having a scrolling menu on this is a step back in the UI, especially considering most people only want to go back a few steps. I like the IE solution that Blake described in comment 8.

It seems pretty obvious that this group is dedicated to limiting a users ability to do what he wants.

Dean, I don't really understand the description in comment 8. > Having a scrolling menu on this is a step back in the UI, Why? If you don't use the scrolling, it is the same as before, only using the available space. The difference is only a few pixels for the arrow where you could scroll. > especially considering most people only want to go back a few steps. That is your assumption. One example which bugs me all the time is entering a frame site. You often get many history entries and cannot easily get back to before it. pi

> I don't really understand the description in comment 8. Here's a screenshot of it. The "patch in action" screenshot in attachment 121636 [details] shows a scrolling menu. If you ask me, scrolling menus are not at all easy to use and should be avoided. I think a combination of extending the number of items in the Back menu to 15 or so plus the History item at the bottom would greatly expand on the current functionality.

Yuck. That means "go all the way back to the beginning", which is a function I use on a daily basis, will be ... let's see how many operations: * Click on the back menu. * Swoop down to the history choice. * Click. * Wait for window to appear. * Scroll that window all the way to the end. * Click. Compare the way it works with the patch as posted: * Click on the back menu. * Swoop all the way down to the end, however far that is. * Click. Can you understand why the second is a better user interface than the first?

Can we at least get the back menu increased to something reasonable like say 30 items? I would love to have it unbounded, but 30 would be great while the discussion of removing the hard limits continues.

The old patches bitrotted.

Comment on attachment 101274 [details] [diff] [review] Patch to make back menu history truly unbounded Patch does not fit anymore (1.4 branch). Marking obsolete. Would it be possible to have a patch which uses all the available space, but no more (i.e., no scrolling)? pi

Comment on attachment 124413 [details] [diff] [review] New patch to increase back menu to 25 items There should be no complaints against this patch. Even the URL dropdown has up to 30 entries.

Cleaning obsolete keyword and status whiteboard. pi

yuck. the url bar dropdown may have 30 items, but it still only shows around the last 10 without scrolling with risk of pissing of people who hate heuristics in user interfaces, there is a really basic heuristic that lists of items should be 7+/-2 in length. Sure you're an engineer so you can deal with large lists, but to some shmoe who just wants to browser, huge lists like this become instantly overwhelming and use of the feature will be dropped.

Why don't we just make it user configurable? Obviously some people can't stand more than 15 items in those menus and others can't live without unlimited history items. I personally would love a lot more than 15, because I constantly find myself going back more than 15 pages at a time and it's a pain to have to hit the back button more than once to get to where you want to go.

No more prefs.

Good idea, Jeff. 15 is way to short. It doesn't need a UI. pi

I like Safari way of handling this. Back and Forward buttons display only last 10 items. History menu displays only last 10 items too, but it also displays an additional submenu "Earlier Today" if there are more then 10 items. The submenu is actually a scrolling menu, so if there are even more items and they don't fit on the screen, it displays scrolling arrows. Well, I don't think we can just copy this behaviour, since we use "Go" menu (not "History"). But we could add submenus to the back and forward buttons if they are needed.

Comment on attachment 124413 [details] [diff] [review] New patch to increase back menu to 25 items well, sr- then :)

Yeah, 7+/-2 is a commonly thrown around heuristic. It happens to be the wrong heuristic to apply in this case. The proper heuristic is "zero, one, infinity" -- in other words, if you are going to give the user the option to go back more than one page at a time, you should give him/her the ability to go back as far as he/she wants. No limit. I don't understand how anyone can stand the current behavior. I can only assume that the people who are arguing for short Back menus never use the Back menu. Having to go back in hops of 15 is *horrible* user experience. I do not think anyone will be confused by a long menu. The comparison to the Bookmarks menu is apt -- there's no limit there, and you see no one complaining about that. Oh, and I don't like the length limit on the URL dropdown either.

I'm with Zack on this. The people that don't want it must never use a frames site. Since no one can agree on the back button can someone at least make the Go menu scrollable so we can get around this snag?

Again long time of silence to this bug. What do we do? It is treated as WONTFIX for no clear reason:-( We need the people in charge to clearly state which solution they would accept. It is not a solution to have a nice looking but useles menu. pi

Is anyone going to address this issue?

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

I have no idea why this would be obsolete. Anyhow: How about making the length of the menu an option? That would serve everybody. pi

this is still a bug dammit. blowing off bugs because they were reported against old versions of the browser (especially when it's trivial to look and see that the bug is still present in the current version) is atrocious. i would _like_ to fix the product and component but i'm not allowed.

zackw@panix.com: just file a new clean bug against the product of your choice. please don't harm this bug by trying to move it to another product. note that based on the comments here, i can't imagine you'd get better results in some other product. dean/neil: are you willing to accept the safari way (comment 62)?

Actually, if there were exactly 10 entries I would want to display them all without a submenu, but then bump the 10th into the submenu if there were more.

What would be the component to file a new bug? And why limit a list (this is not a menu where you have entries, it is just an ordered list) to ten entries. Why not let people decide with an option? pi

The idea is, that there are entries for the most used cases where people don't want to go back alot, plus the More option for those who do.

Often you have the problem that once you enter a site, you go over several pages. Then you want to go back to the page before this site, which is often out of reach. There might be people who don't use this, people who might not even be aware of the back menu. But there are people who do want this. So why make it complicated? Just last week I observed someone who had his bookmarks imported from Netscape 4. This was a huge list, not really organized. So he had to scroll a lot to even reach his bookmarks (Netscape 4 opens them in submenus). On the other hand we cut the back menu at very few entries, far before reaching the bottom of the screen. pi

Why are people so against making this user configurable? You want 15, fine you can have 15. You want 40, then you can have that too. Everyone is happy. I don't understand the aversion to changing what is probably a hardcoded constant in the code.

You are not alone Jeff. I have asked roughly the same thing and have been wondering for what seems like years now. They never really responded.

There seems to be an aversion to adding prefs from the Mozilla owners. Not sure why this is. I'm fighting the same issue of hard coded values for cookies with Bug 202690.

(In reply to comment #78) > I'm fighting the same issue of hard coded values for cookies with > Bug 202690. Sorry, I meant Bug 213963.

*** Bug 192184 has been marked as a duplicate of this bug. ***

It appears that they are going to continue this nonsense into Firefox. I was hoping that someone in that group would realize that they are supposed to be at least trying to please their public.

Say Jeff: Switch to Camino. The people writing Camino have already fixed this issue. I have been using it for quite a while now and it's Great. I hadn't noticed that this was resolved until I switched to FireFox and the problem came back. Firefox refered me back to this Bug. :) It seems they have the same people in charge.

Just switched to Firefox since Mozilla is dieing. Might check out Camino, but it's kinda behind the rest of the code base.

I have filed Bug 287277 against Firefox. See if anything comes of it.

Good luck Jeff. I haven't had much luck dealing with the Firefox people. A word of advice. Don't mention anything about adding preferences, just state what you want as a feature addition. See bug 282482.

Long time no activity. I would assume it is bitrotten by now (since I cannot compile myself, I cannot test). It would be great to include the patch in the way that a preference will determine the length of the menu. pi