104142 - want infinite Back

Status: RESOLVED WONTFIX

(Firefox :: General, enhancement)

Description

[Zack Weinberg (:zwol)]

Currently there is a hard, rather small limit on the length of the trail which
the Back button will retrace over.  If you exceed it, pages are silently dropped
off the end.

There should be no such limit.  No matter how far I have browsed I should be
able to get all the way back to the beginning.

[Note this is not the same as bug 62010.  That bug is about the length of the
drop-down menu.  This is about the total length of the session history.]

Comment 1

[Jesse Houwing]

That's what History is all about isn't it? I think it isn't a need for the back
button but that's my opinion...

btw someone should add [RFE] to the summary... I'm not allowed :(

Comment 2

[Mike Young]

ummm. If I'm correct, you can go back to the earliest document in the dropdown
and then when you open the dropdown again it will repopulate with even earlier
documents. So you keep using the back menu to eventually go back all the way. As
far as I know there is no actual limit where the URLs are "forgotten" 

If there is a limit, please provide us with the number of URLs that you see.
If there is no limit, and you just want the dropdown to be really really long
(possibly with an scroll arrow) Then this is a dup of bug 62010

Comment 3

[Zack Weinberg (:zwol)]

I have already compared this bug to 62010.  There really is an actual limit
where pages are forgotten.  You can most easily see the limit by reading all
the way through a long thread in a mailing list archive and then trying to get
back to the index (I do this on a daily basis).

Since filing the bug I've discovered the "Number of pages in session
history" preference (under Navigator > History) - its default value is 50,
which is indeed the length I was seeing.  Bumping it way up makes me much
happier.  But I still want no limit at all.

Comment 4

[Ashley Bischoff (blog at handcoding.com)]

Mike: I believe the reporter is correct. As mentioned, reading a long thread on
a message board would be a good test.

No dupes found, but dupes suspected. Marking NEW. 

-> All/All

Comment 5

[Andrew Hagen]

What is the hardcoded limit?

Comment 6

[Zack Weinberg (:zwol)]

Andrew: There isn't a fixed limit.  The limit is the "Number of pages in
session history" preference.  What I'm asking for is a "no limit whatsoever"
option for that preference.

Comment 7

[Andrew Hagen]

Why don't you set you session history preference to 500 or 1000? Would that be
practically the same as an infinite amount?

Comment 8

[Zack Weinberg (:zwol)]

I have done so.  But it's not good enough.  If I set it to 500, I'm hosed the
moment I go 501 pages deep in the session history.

I expect to be able to go as deep as I bloody well want, until the computer runs
out of memory, and *still* be able to get all the way back to the beginning.

Comment 9

[Ian Nartowicz]

Duplicate of 62010.

Comment 10

[Boris Zbarsky [:bzbarsky]]

We could make the magic number "-1" mean "unbounded", but we'd need to change
the UI to have a checkbox or something (so check that to limit, then set limit)....

Comment 11

[Boris Zbarsky [:bzbarsky]]

Er... actually, -1 already means unbounded and there is no UI for this pref at all.

So what's left to do here?

Comment 12

[Boris 'pi' Piwinger]

As you say, there is no UI. Obviously, nobody did know about that -1. Where
exactly do I have to set it and what is the exact effect?

Bug 62010 is about making that history accessible. This is not a dupe.

pi

Comment 13

[[e-mail]]

The pref is browser.sessionhistory.max_entries but you must change all.js

Comment 14

[Boris 'pi' Piwinger]

Why do I need to change all.js? about:config has the entry (default=50).

If the change is really needed, then maybe you can provide a patch.

pi

Comment 15

[[e-mail]]

You have cug 126826 to thank for that behaviour...

Comment 16

[Boris 'pi' Piwinger]

OK, but despite bug 126826, could that be fixed as you suggested without causing
the problems solved there?

pi

Comment 17

[[e-mail]]

I'm not exactly sure what you mean, but if you edit all.js and change 50 to 0
then your back and forward buttons will stop working.

Comment 18

[Boris 'pi' Piwinger]

So what exactly is the change you suggested in comment 13? How can this bug be
fixed whithout causing the problem that the buttons stop working?

pi

Comment 19

[[e-mail]]

It looks as if the pref is in browser-prefs.js these days, find the line

pref("browser.sessionhistory.max_entries", 50);

and change 50 to 0 to disable the buttons or to -1 for indefinite back.

Comment 20

[Boris 'pi' Piwinger]

Would this be the way to fix this bug? Maybe you can prepare a patch, I don't
understand enought to do it. Thanks.

pi

Comment 21

[[e-mail]]

What I'm trying to say is that although Mozilla supports indefinite back,
editing your local copy of browser-prefs.js is the only way to access it.

Comment 22

[Boris Zbarsky [:bzbarsky]]

What _I_ am trying to say is that this bug is in thre wrong component, since
it's just about exposing UI for existing session history functionality.

Comment 23

[timeless]

Attachment: honor user prefs

Comment 24

[[e-mail]]

Comment on attachment 148186 [details] [diff] [review]
honor user prefs

>   if (prefs) {
>-    nsCOMPtr<nsIPrefBranch> defaultBranch;
>-    prefs->GetDefaultBranch(nsnull, getter_AddRefs(defaultBranch));
>-    if (defaultBranch) {
>-      defaultBranch->GetIntPref(PREF_SHISTORY_SIZE, &gHistoryMaxSize);
>+    nsCOMPtr<nsIPrefBranch> branch;
>+    prefs->GetBranch(PREF_SHISTORY_BRANCH, getter_AddRefs(branch));
>+    nsCOMPtr<nsIPrefBranchInternal> pbi = do_QueryInterface(branch);
>+    if (pbi) {
>+      pbi->AddObserver(PREF_SHISTORY_SIZE, this, PR_TRUE);
>+      Observe(pbi, NS_PREFBRANCH_PREFCHANGE_TOPIC_ID, nsnull);
>+    }
Your pref branch internal has now gone out of scope, gets released, and stops
sending change notifications. But do you really want each session history
object to register for notifications? I have about 100 ;-)

Anyway, this patch regresses bug 126826.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 148186 [details] [diff] [review]
honor user prefs

Neil, the scope thing is a non-issue -- the prefbranch object is not what sends
the notifications.

The only issue I see with this patch is that Observe() could use aSubject to
get the prefbranch, no?  Would be faster/simpler....

Comment 26

[Michiel van Leeuwen (email: mvl+moz@)]

The scoping would only be a problem if you would use the aSubject as the
prefbranch. If you do that, it will have forgotten its branch, and default to
empty. But in this case, a new prefbranch is created, so it should work.

Comment 27

[timeless]

neil's right, the items do go away.

the root problem that caused the bug neil mentioned is that no one calls
AddSHistoryListener.

Comment 28

[timeless]

Attachment: honor user prefs and listen for purge

Comment 29

[timeless]

Comment on attachment 148289 [details] [diff] [review]
honor user prefs and listen for purge

I'm missing two lines, please forgive me:

...
>+             function SHistoryListener(){this.window = window};

function SHistoryVoid(){};

>+             function SHistoryTrue(){return true;};
>+             SHistoryListener.prototype = {
>+               QueryInterface: function QueryInterface(iid) {
...
>+               },

OnHistoryNewEntry: SHistoryVoid,

>+               OnHistoryGoBack: SHistoryTrue,
...

Comment 30

[Boris Zbarsky [:bzbarsky]]

Er.... could you actually post a complete patch?  And it may take me a while
(weeks) to get to this -- I'm not very familiar with the listener stuff and
would have to figure it out.   :(

Comment 31

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 148289 [details] [diff] [review]
honor user prefs and listen for purge

Marking sr- per that last comment.  Note that I will not be able to look at
this again until July 11 at least.

Comment 32

[[e-mail]]

Comment on attachment 148289 [details] [diff] [review]
honor user prefs and listen for purge

This appears to regress bug 126826. Also if you are going to watch for history
pref changes I think browser.xml or navigator.js would be a better place.

Comment 33

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 34

[Zack Weinberg (:zwol)]

I don't know if this is still a problem with Seamonkey but it definitely is with Firefox, and the original description of the bug is still correct.  I'm taking the third option of reassigning the bug to Firefox:UI Design.

Comment 35

[Mike Connor [:mconnor]]

This is certainly not something I anticipate us doing by default, especially with tabbed browsing enabled most users rarely go back more than ten pages (we've seen enough studies on this, they're cited in other bugs but I don't feel like digging for the links).  50 is entirely sufficient for our purposes.

Comment 36

[Asa Dotzler [:asa]]

(In reply to comment #35)
> This is certainly not something I anticipate us doing by default, especially
> with tabbed browsing enabled most users rarely go back more than ten pages
> (we've seen enough studies on this, they're cited in other bugs but I don't
> feel like digging for the links).  50 is entirely sufficient for our
> purposes.

Is there some penalty (performance?) to having an infinite back? If there's no penalty, I can see no reason to cap it. If there's a penalty then we should consider test-piloting and make sure our number is really ideal and not the seemingly arbitrary 50.

Comment 37

[Zack Weinberg (:zwol)]

Man, I seem to have been in a rotten mood eleven years ago when I filed this bug.  I'd like to apologize for that now.

My use case for unbounded session history (within a single tab) is still well described by comment 3: I regularly read mhonarc-style mailing list archives on the web (for various free software projects that I don't participate in enough to want all the mail, but I still want to keep track of what they're doing).  Each message in such archives gets its own page.  I want to be able to click "thread next" until I get to the end of a thread, no matter how long it is, and then use the history dropdown to get all the way back to the message index, ideally in one action.  (Yes, there's a link to the message index on every page of such archives, but it's got a fragment identifier on it that means I lose my original scroll position in the index.)

I don't hit the session history limit nearly as often nowadays as I did eleven years ago -- mainly because my patience with ridiculously long threads is not what it used to be, and secondarily because I have learned to avoid this bug by opening threads in new tabs from the index -- but I do still sometimes hit it and it's a papercut-level irritant each time.

(I *do* frequently want to go back further than the number of things shown in the history dropdown, and that's rather more irritating than a papercut, but that's also not this bug. :-)