162728 - session history completely missing from Windows build 2002081308

Status: CLOSED DUPLICATE of bug 162593

(SeaMonkey :: Installer, defect)

Description

[Peter Stein]

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

Comment 1

[Sam J. Fleet]

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.

Comment 2

[Radha on family leave (not reading bugmail)]

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

[John Morrison]

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).

Comment 4

[Peter Stein]

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

[John Morrison]

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.

Comment 6

[Peter Stein]

user_pref("browser.sessionhistory.max_entries", NNN);

is not present in prefs.js.

Comment 7

[John Morrison]

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.

Comment 8

[Peter Stein]

Yes, it's present in all.js

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

Comment 9

[John Morrison]

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

Comment 10

[Peter Stein]

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

[John Morrison]

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

[John Morrison]

see also bug 160980, where an outdated compreg.dat is causing bugs in the 
personal toolbar.

Comment 13

[Peter Stein]

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.

Comment 14

[Peter Stein]

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.

Comment 15

[Radha on family leave (not reading bugmail)]

I'm giving to jag who might find this bug related to otehr ones he has in this
area. 

Comment 16

[John Morrison]

> 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

Comment 17

[John Morrison]

... and speaking of errors, I typed in some of the wrong info :-/

One more time ...

-> Installer, to remove compreg.dat during uninstall

Comment 18

[Henrik Gemal]

isn't this dupe of 162593 ?

Comment 19

[John Morrison]

*** This bug has been marked as a duplicate of 162593 ***

Comment 20

[Wesha]

v.