Open Bug 62010 Opened 24 years ago Updated 15 years ago

Back menu session history should be unbounded

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: schapel, Assigned: jag+mozilla)

References

Details

(Keywords: helpwanted, polish)

Attachments

(3 files, 4 obsolete files)

Screenshot of patch in action
52.05 KB, image/png
Details
IE's Back button
5.61 KB, image/png
Details
New patch to increase back menu to 25 items
475 bytes, patch
janv
: review-
alecf
: superreview-
Details | Diff | Splinter Review 
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Increase session history displayed in Back button dropdown menu → [RFE] Increase session history in Back Button
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?
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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.
Assignee: radha → vishy
Status: ASSIGNED → NEW
Component: History: Session → Browser-General
Component: Browser-General → XP Apps: GUI Features
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
Assignee: vishy → mpt
Component: XP Apps: GUI Features → User Interface: Design Feedback
QA Contact: claudius → zach
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.
Assignee: mpt → radha
Component: User Interface Design → History: Session
Keywords: polish
OS: Windows 2000 → All
QA Contact: zach → claudius
Summary: [RFE] Increase session history in Back Button → Back menu session history should be unbounded
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.
Keywords: mozilla1.2
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.
Attachment #101153 - Attachment is obsolete: true
Attached patch Patch to make back menu history truly unbounded (obsolete) — — Splinter Review 
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.
Attachment #101156 - Attachment is obsolete: true
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.
Depends on: 104142
Keywords: patch
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
Whiteboard: fix in hand, needs r=, needs sr=, needs a=
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
Attachment #101274 - Flags: review?(radha)
We have a patch, this could easily be in 1.3b which would be a great improvement.

pi
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
Attachment #101274 - Flags: review?(radha) → review?
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
No longer depends on: 104142
Keywords: mozilla1.2 → mozilla1.3
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.
Assignee: radha → sgehani
Component: History: Session → Browser-General
Over to XP Apss: GUI Features. Hopefully, it is correct there.

pi
Component: Browser-General → XP Apps: GUI Features
Attachment #101274 - Flags: review? → review?(jaggernaut)
Whiteboard: fix in hand, needs r=, needs sr=, needs a= → fix in hand, needs r=, needs sr=
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
Attachment #101274 - Flags: superreview?(claudius)
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.
Attachment #101274 - Flags: superreview?(claudius)
Attachment #101274 - Flags: superreview?(alecf)
Attachment #101274 - Flags: review?(radha)
Attachment #101274 - Flags: review?(jaggernaut)
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
Attachment #101274 - Flags: review?(radha) → review?(sgehani)
Attachment #101274 - Flags: review?(sgehani) → review?(varga)
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.
Attachment #101274 - Flags: superreview?(alecf) → superreview-
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.
.
Assignee: sgehani → blaker
QA Contact: claudius → paw
Attached image Screenshot of patch in action — 
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
Attachment #101274 - Flags: superreview- → superreview?(alecf)
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.
Attachment #101274 - Flags: superreview?(alecf)
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
Attached image IE's Back button — 
> 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.
Attachment #101272 - Attachment is obsolete: true
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
Attachment #101274 - Attachment is obsolete: true
Attachment #101274 - Flags: review?(varga)
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.
Attachment #124413 - Flags: superreview?(alecf)
Attachment #124413 - Flags: review?(varga)
Cleaning obsolete keyword and status whiteboard.

pi
Keywords: mozilla1.3
Whiteboard: fix in hand, needs r=, needs sr=
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.
Attachment #124413 - Flags: review?(varga) → review-
Comment on attachment 124413 [details] [diff] [review]
New patch to increase back menu to 25 items

well, sr- then :)
Attachment #124413 - Flags: superreview?(alecf) → superreview-
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.
Assignee: firefox → guifeatures
Target Milestone: Future → ---
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)?
Assignee: guifeatures → neil.parkwaycc.co.uk
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.
Keywords: helpwanted
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.
Product: Core → Mozilla Application Suite
*** 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.
Component: XP Apps: GUI Features → UI Design
Assignee: neil → jag
Priority: P3 → --
QA Contact: pawyskoczka
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
QA Contact: ui-design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: