Session history is missing from the history preferences panel and the back and forward buttons are not functional.
try to make a backup copy of the directory "mozilla.org/mozilla". This can be done with copying it to the desktop with the right mouse click option. Then delete all files and folder under the "mozilla.org/mozilla" folder except the plugin. Then re-install it with the recently nightly build you got.
I understand that session history was removed from the history prefs panel( about a week ago) to avoid confusion with global history preference. May be that broke the default # of entries Session history holds. Please provide a build id and platform info.
The removal of that pref panel (bug 155712, checked in Jul 31) only removed the front end UI. I can't imagine how it could impact the actual pref value. This seems more like these other issues where back/forward get mysteriously disabled. (Although, as we discussed, I have wondered about hard-coding a lower bound on that value, e.g., never less than 7).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Build ID and platform info are present in the original report. From the comments to date it isn't clear what if anything I can do to obtain a working version. If I should download an older version someone should indicate which version has this functional, but is as current as possible.
Peter: can you have a look at the file 'prefs.js' in your profile directory which on win2k will be something like: C:\Documents and Settings\Administrator\Application Data\Mozilla\Profiles\<name>\<xxxxxxxx.slt>\prefs.js and look for a line that says: user_pref("browser.sessionhistory.max_entries", NNN); 'NNN' should be 50 (or some similarly sized number) and should not be zero. If it is zero, then shut down mozilla, and edit that line to say '50'. If it's not zero, then the problem lies elsewhere.
user_pref("browser.sessionhistory.max_entries", NNN); is not present in prefs.js.
Okay, if it's not present, then it takes the value from the install pref file. Can you look in <mozilla directory>\defaults\pref\all.js for that string? If it says 50, then session history's pref is set correctly, and that's not the problem.
Yes, it's present in all.js I added it to prefs.js, but that had no impact.
Thanks. Have you doing a clean install (i.e., into a new directory) as suggested in comment 1?
Yes, I tried the comment 1 recommendation, but it has no impact on this problem (it did seem to solve an unrelated problem with the location bar though). The last time I checked the "clean install" procedure still consisted of uninstalling first via "add/remove programs". Don't the plugins stay intact if this is followed?? It would be real annoying to users if they had to redownload all their plugins.
Um, uninstalling via "add/remove software" will leave the Plugins folder intact as well as certain other items. Sorry, but I'm not entirely clear as to how you did the re-install. Did you use "Add/Remove Programs" to initially remove the program? Can you try this, in either case: create a directory C:\thisjunk and install mozilla into that directory and see if that works. (I'm certain that this is a problem with reinstalling over top of an existing installation, and that if you install into a completely empty directory, this will work.) At any rate, I tried using the "Add/Remove" method of uninstalling and noted that, among other things, 'compreg.dat' is not removed along with the rest of the components. And it is not reregistered when a new build is installed overtop of the old build location. That's definitely a bug (probably this bug). Is there a bug on file for the installer not removing 'compreg.dat'?
see also bug 160980, where an outdated compreg.dat is causing bugs in the personal toolbar.
I've always uninstalled the existing version of Mozilla using "add/remove" before installing a newer version. How can something as fundamentally important as the installer be screwed up? And if the installer is at fault why hasn't this surfaced before? At any rate I'll give a new install directory a try.
Ok, installing into a new directory did the trick. There still is no "session history" under "history preferences", but at least the back and forward buttons work. I'm not sure I understand what's going on here. Comment 1 had me delete everything except the plugins directory - that didn't work. This new install did the same thing, with the addition of a new plugin directory. So is the conclusion that old plugin(s) somehow fouled the install? The other possibility is that something outside of the "mozilla.org/mozilla" folder was responsible (which again raises the question what the point of comment 1 was). I don't see how that would be affected by installing into a new directory though. It's all clear as mud. I'll be sure to use the Linux recipe (delete old Mozilla in entirety) for new installs from now on.
I'm giving to jag who might find this bug related to otehr ones he has in this area.
Assignee: radha → jaggernaut
> There still is no "session history" under "history preferences" Yes. That is expected. It was removed in current builds since the concept of session history is more abstract than almost any end user would be interested in (i.e., what value are they supposed should they choose? How would they decide?). > How can something as fundamentally important as the installer be screwed up? This is a true statement for any 'release' build. However, errors (regressions) do occasionally creep into the build and are not immediately apparent. Having thorough feedback in bugzilla (like your feedback has been) from users testing 'nightly' builds helps to flush out these sort of errors. At any rate, the problem here is that the 'component registry' (compreg.dat) changed filename and format a while ago, and the appropriate uninstall information has not apparently been updated to remove that file when the rest of the build is removed. So, what happens is that as components (in dlls) change their interfaces, etc., the new information is not detected. And this leads to failures in using those components. -> Installer, to remove compreg.dat during uninstall
Assignee: jaggernaut → radha
Severity: normal → major
... and speaking of errors, I typed in some of the wrong info :-/ One more time ... -> Installer, to remove compreg.dat during uninstall
Assignee: radha → dveditz
Component: History: Session → Installer
QA Contact: claudius → bugzilla
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.2alpha
isn't this dupe of 162593 ?
*** This bug has been marked as a duplicate of 162593 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.