Status

()

--
enhancement
RESOLVED WONTFIX
17 years ago
5 years ago

People

(Reporter: zwol, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

17 years ago
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

17 years ago
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

Summary: want infinite Back → [RFE] want infinite Back
(Reporter)

Comment 3

17 years ago
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Future

Comment 5

17 years ago
What is the hardcoded limit?
(Reporter)

Comment 6

17 years ago
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

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

Comment 8

17 years ago
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.

Updated

16 years ago
Blocks: 62010

Updated

16 years ago
Summary: [RFE] want infinite Back → want infinite Back

Comment 9

16 years ago
Duplicate of 62010.

Updated

16 years ago
No longer blocks: 62010
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)....
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

15 years ago
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

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

Comment 14

15 years ago
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

15 years ago
You have cug 126826 to thank for that behaviour...

Comment 16

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

pi

Comment 17

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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.
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.
Assignee: radha → guifeatures
Component: History: Session → XP Apps: GUI Features
QA Contact: claudius
Target Milestone: Future → ---

Comment 23

15 years ago
Created attachment 148186 [details] [diff] [review]
honor user prefs

Updated

15 years ago
Attachment #148186 - Flags: superreview?(bzbarsky)
Attachment #148186 - Flags: review?(neil.parkwaycc.co.uk)

Comment 24

15 years ago
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.
Attachment #148186 - Flags: review?(neil.parkwaycc.co.uk) → review-
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....
Attachment #148186 - Flags: superreview?(bzbarsky) → superreview-
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

15 years ago
neil's right, the items do go away.

the root problem that caused the bug neil mentioned is that no one calls
AddSHistoryListener.
Assignee: guifeatures → timeless

Comment 28

15 years ago
Created attachment 148289 [details] [diff] [review]
honor user prefs and listen for purge
Attachment #148186 - Attachment is obsolete: true

Updated

15 years ago
Attachment #148289 - Flags: superreview?(bzbarsky)
Attachment #148289 - Flags: review?(neil.parkwaycc.co.uk)

Comment 29

15 years ago
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,
...
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 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.
Attachment #148289 - Flags: superreview?(bzbarsky) → superreview-

Comment 32

14 years ago
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.
Product: Core → Mozilla Application Suite

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design

Comment 33

9 years ago
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
Status: NEW → UNCONFIRMED
(Reporter)

Comment 34

9 years ago
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.
Assignee: timeless → nobody
Component: UI Design → General
Product: SeaMonkey → Firefox
QA Contact: general
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX

Comment 36

7 years ago
(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.
(Reporter)

Comment 37

7 years ago
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. :-)

Updated

7 years ago
Attachment #148289 - Flags: review?(neil)
You need to log in before you can comment on or make changes to this bug.