Wizard-run installs get wrong directories

VERIFIED FIXED in M9

Status

defect
P1
blocker
VERIFIED FIXED
20 years ago
2 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Assignee

Description

20 years ago
When the wizard launches installs through xpistub.dll the installs all think
the program directory is where the wizard is, not where xpcom is.
 - files installed in the wrong place
 - component.reg in the wrong place
 - install.log in the wrong place
 - SmartUpdate page won't be able to find the registered stuff (registered
under wrong Communicator directory)

Not sure we have many options. There may be some way to hack nsFileSpec so we
can fake it out about where the program directory is. Other than that, the
wizard will have to lauch a new process to do the install (i.e. xpistub.EXE).

A separate process means the wizard will have trouble showing the progress. We
could have the wizard simply launch apprunner to do it, or get into the muck of
inter-process communication.

Updated

20 years ago
Severity: normal → blocker
Priority: P3 → P1
Target Milestone: M9
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Assignee

Comment 1

20 years ago
Samir should be on this one too.

Do the Mac and Win wizards work the same way? The wizard itself goes in a temp
dir. The first version Sean showed me had the core unpacked and run in the
final dir, with all of the problems already listed (the wizard was considered
the app). Later I Sean mentioned he was going to unpack the core also in the
temp dir, but then XPInstall it into the final dir.

One advantage of that is that the basic script wouldn't have to overwrite the
new files. That would be a nice thing on Win9x, and would also leave more
reassuring messages in the install.log.  It also helps with this problem if we
can agree to do it this way for both wizards. For one thing I think we'd only
have to hack xpinstall to handle this rather than the core directory service.

In this scenario xpistub would call AutoReg with NULL to initialize XPCOM in
the temp directory -- creating a temp components.reg. xpistub would still have
to be passed the target directory, which it will use to override the "Program"
directory, the version registry directory, and the location of the install log
(if we want the initial install to create one).

At the end of the script we'd have to somehow register the new files. But
that's OK because our scripts will have to be able to do that anyway in order
for XPInstall upgrades to work.

Any future thoughts about this plan? Is the double-install of the core files an
OK plan?
Assignee

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Assignee

Comment 2

20 years ago
The solution I tried was to fool XPInstall about the Program directory, but
leave the deeper concept of Process dir alone. The install.log and the
components.reg still are created in the wizard directory. It appears to work OK
if the components.reg cannot be created (as would be the case with a CD
install, for instance)

This may not be the end of it...

Comment 3

20 years ago
This will be and only can be verified when the install wizard uses xpinstall to
install xpis.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 4

20 years ago
Build 9/24/99

This installer appears to install fine.  Marking Verified.

Comment 5

20 years ago
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.