Closed Bug 197466 Opened 22 years ago Closed 17 years ago

Back button (session history) has 50 entries regardless of setting in prefs.js

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9beta4

People

(Reporter: zug_treno, Assigned: zug_treno)

References

Details

Attachments

(1 file, 4 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 If I set the browser.sessionhistory.max_entries setting to either a lower (10) or a higher (250) number, the actual number of entries stays at default (50). Reproducible: Always Steps to Reproduce: 1. Change browser.sessionhistory.max_entries to another number using about:config. 2. Surf to more then that number (or 50: whatever number is lower) pages. 3. Use the dropdown list from back button to go back as far as possible. Actual Results: It will go back to up to 50 entries. Expected Results: It should go back up to the number set in browser.sessionhistory.max_entries. This happens with both an old profile and a brand new profile, using the classic theme.
Could this bug be something to do with the recent changes in that part of the code?
See bug 126826. Basically, the user pref for this was removed; non-user prefs (from all.js) will still work. We _could_ follow the user_pref if and only if it's set to be above the non-user one, perhaps....
I'd suggest wontfix. Hack your own copy of 'all.js' if you really want 714 session history entries.
I changed pref("browser.sessionhistory.max_entries", 50); in all.js, but 50 is still the magic number. Are there any other settings or files that should be changed?
Is this also the case if you quit mozilla (and quicklaunch) before editing prefs.js or all.js?
worksforme. setting |pref("browser.sessionhistory.max_entries", 100);| in all.js allows me to get more than 50 entries in session history.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
oops
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
wontfix
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WONTFIX
All.js setting WFM after some experimentation: it picked up the new default value after I deleted the backup copy of all.js in the same directory. I really hope this all.js setting won't dissapear in future releases like the one in prefs.js. Everybody thanks for the help.
Nowadays the browser.sessionhistory.max_entries setting can be found in (\Program Files\mozilla.org\Mozilla\defaults\pref\) browser-prefs.js.
*** Bug 280571 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > We _could_ follow the user_pref if and only if it's set to be above the non-user > one, perhaps. It seems that Minimo has the lowest default pref (10 entries), so this patch uses the browser.sessionhistory.max_entries again but any value under 10 is increased to 10.
Assignee: radha → zug_treno
Status: RESOLVED → ASSIGNED
Ever confirmed: true
Attachment #304707 - Flags: review?(bzbarsky)
Resolution: WONTFIX → ---
Wouldn't it make more sense to disallow setting it to below the default, but allow setting it above the default, whatever the default is?
Put another way, I don't want a magic constant here.
Updated patch, the number of session history entries is made equal to the default number of entries if browser.sessionhistory.max_entries is smaller than the default value.
Attachment #304707 - Attachment is obsolete: true
Attachment #304817 - Flags: review?(bzbarsky)
Attachment #304707 - Flags: review?(bzbarsky)
Comment on attachment 304817 [details] [diff] [review] Simple patch to follow user prefs (> default) again Can you do a patch without the tabs (or with, if the file has them)? That would also make it a lot easier to review...
Same patch as before, but with tabs replaced by spaces.
Attachment #304817 - Attachment is obsolete: true
Attachment #304817 - Flags: review?(bzbarsky)
Comment on attachment 304832 [details] [diff] [review] Simple patch to follow user prefs (> default) again, without tabs >Index: docshell/shistory/src/nsSHistory.cpp >+static PRInt32 gDefaultHistoryMaxSize; Why bother having a static for this instead of just a stack local? With that just put on the stack, looks reasonable.
Made defaultHistoryMaxSize a local variable.
Attachment #304832 - Attachment is obsolete: true
Attachment #304945 - Flags: review?(bzbarsky)
Comment on attachment 304945 [details] [diff] [review] Simple patch to follow user prefs (> default) again, with local variable >Index: docshell/shistory/src/nsSHistory.cpp >+ PRInt32 defaultHistoryMaxSize; Please init this to 50 to start with. With that change, r=bzbarsky.
Attachment #304945 - Flags: review?(bzbarsky) → review+
Initializes defaultHistoryMaxSize to 50.
Attachment #304945 - Attachment is obsolete: true
Attachment #305047 - Flags: superreview?(darin.moz)
Comment on attachment 305047 [details] [diff] [review] Simple patch to follow user prefs (> default) again, init variable to 50 I can just r+sr this.
Attachment #305047 - Flags: superreview?(darin.moz) → superreview+
Er, except this would need approval to land on trunk at this point.
Keywords: checkin-needed
Attachment #305047 - Flags: approval1.9?
Comment on attachment 305047 [details] [diff] [review] Simple patch to follow user prefs (> default) again, init variable to 50 a1.9+=damons
Attachment #305047 - Flags: approval1.9? → approval1.9+
OS: Windows XP → All
QA Contact: kasumi → history.session
Hardware: PC → All
Checking in docshell/shistory/src/nsSHistory.cpp; /cvsroot/mozilla/docshell/shistory/src/nsSHistory.cpp,v <-- nsSHistory.cpp new revision: 1.85; previous revision: 1.84 done
Status: ASSIGNED → RESOLVED
Closed: 22 years ago17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: