session history completely missing from Windows build 2002081308

CLOSED DUPLICATE of bug 162593

Status

--
major
CLOSED DUPLICATE of bug 162593
17 years ago
14 years ago

People

(Reporter: nbi, Assigned: dveditz)

Tracking

Trunk
mozilla1.2alpha
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Session history is missing from the history preferences panel and the back and
forward buttons are not functional.

Comment 1

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

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

17 years ago
user_pref("browser.sessionhistory.max_entries", NNN);

is not present in prefs.js.

Comment 7

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

Comment 8

17 years ago
Yes, it's present in all.js

I added it to prefs.js, but that had no impact.

Comment 9

17 years ago
Thanks. Have you doing a clean install (i.e., into a new directory) as 
suggested in comment 1?
(Reporter)

Comment 10

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

Comment 11

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

Comment 12

17 years ago
see also bug 160980, where an outdated compreg.dat is causing bugs in the 
personal toolbar.
(Reporter)

Comment 13

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

Comment 14

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

Comment 16

17 years ago
> 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
Keywords: nsbeta1

Comment 17

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

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.2alpha

Comment 18

17 years ago
isn't this dupe of 162593 ?

Comment 19

17 years ago

*** This bug has been marked as a duplicate of 162593 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 20

17 years ago
v.
Status: RESOLVED → CLOSED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.