11846 - Component registry problems with the ActiveX control

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[locka]

The Mozilla ActiveX control only functions correctly when the host executable is
running from the Mozilla bin directory. When the exe runs from elsewhere, the
control typically "goes the through the motions" of loading a page (firing
download progress events and so on) but nothing is actually displayed. This
suggests that the display elements were not correctly created. In debug builds,
assertions may occur.

The control is registered and all Mozilla dlls are available from the PATH
environment variable. Apprunner has been run beforehand to ensure the component
registry data files are present.

I expect this problem would affect any client application/dll trying to use the
Mozilla layout engine from some other working directory. This immediately
includes the ActiveX control and the Java browser class.

The most straight forward way to demonstrate the problem is to build the CBrowse
test harness in mozilla/webshell/embed/activex/tests/cbrowse.  Run cbrowse.exe
from outside the bin directory and try browsing to a page, then copy cbrowse.exe
to the Mozilla bin directory and do the same thing. Only the cbrowse.exe running
in the directory should work correctly. The CBrowse test harness starts with a
configuration dialog that allows Mozilla logging options to be set.

Comment 1

[Suresh Duddi (gone)]

I understand. The component registry is read off the bin directory of the app.
That is the issue.

For your stuff, I think we need a way for pointing to mozilla's registry which
maynot exist in the bin directory.

Comment 2

[locka]

An additional way to demonstrate (probably) the same problem.

Copy apprunner.exe to Somewhere Else.
Add the Mozilla bin directory to the PATH environment variable (so all DLLs
resolve etc)
Run the copied apprunner.exe

Boom.

In theory it should work the same since the Mozilla dlls are there to be found
and the mozregistry.dat in windows directory could or should allow the apprunner
to locate all the components.

Perhaps there could be a function to explicitly set where the component root is?
The Mozilla control could call this at startup using the path to itself
(npmozctl.dll) as the parameter. If the function is not called, the default
behaviour could be to read c:\windows\mozregistry.dat for the answer and failing
that assume it to be the current directory.

Comment 3

[locka]

The new changes appear to work reasonably well so I'm closing it as fixed for
me.

There are a couple of outstanding problems though that should be resolved.

Firstly, the two optional nsFileSpec parameters should be copied because they
are used later for hash table lookup. I was originally caught out when my
parameters went out of scope and the lookup failed.

Secondly, the NS_Init/ShutdownXPCOM methods need to be refcounted for embedded
controls since they have no knowledge of any other control/app that may be using
XPCOM.

Comment 4

[Suresh Duddi (gone)]

I fixed the copying already.

The refcounting is a problem still. Can we talk about this in the newsgroup.