8682 - component.reg uses absolute path names

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Hixie (not reading bugmail)]

When starting Apprunner from a UNC after Apprunner has been started from the
same directory on the machine itself (i.e., when starting the same Apprunner
installation from a different directory), I get a deluge of messages along the
lines of:


**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/prefwind.dll) FA
ILED with error: error 0
**************************************************
*** Registering html library
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************


This is very bad. I should be able to run Apprunner from any path without
deleting the registry file.

Comment 1

[Hixie (not reading bugmail)]

See also a comment by chofmann in bug 7916.

Comment 2

[Suresh Duddi (gone)]

I just ran two instance of apprunner from the same directory on my NT  machine
and that worked.

Could you let me know what build you are using and something more about UNC

Comment 3

[Suresh Duddi (gone)]

I read bug# 7916

I think moving the component.reg along with the binary in the <exedir> should
have fixed this.

Let me know if this aint the case. This got fixed a week ago atleast.

Comment 4

[Hixie (not reading bugmail)]

The problem was poorly described. My apologies.

Steps to reproduce:
   Unzip mozilla archive into a folder, say c:\mozilla\
   Run apprunner from there.
   Share the folder.
   Assuming your machine is called "foo", and the share is called "bar",
    go to "\\foo\bar". i.e., using "Network Neighborhood", go to the
    share containing apprunner.exe.
   Run apprunner from there.

UNC stands for Universal Naming Convention, i.e., a network path in the form
   \\machine\share\path\file

The build I used is Sunday's. Deleting the component.reg file solved the problem
(or rather, it precipitated bug 8684...).

Can you reproduce the problem using the steps above?

Comment 5

[Suresh Duddi (gone)]

Ah ha! I know why you are seeing this. And I am sad that this is by design. :-(

Of course, we have to change the design to fix this. We will.

The problem is that component.reg is with the exe and all the component dlls are
registered with full pathnames. When run from two different paths pointing to
the same installation, the component registry is still pointing to the old
pathnames.

Fix would be to store relative pathnames in the component registry. Would it be
ok if I change the summary of the bug appropriately.

Comment 6

[Suresh Duddi (gone)]

Steve/Bhuvan can you help implement relativeness in nsFileSpec. Then I can use
it to implement relative pathnames in the registry.

Comment 7

[Suresh Duddi (gone)]

Component registry uses relative path.