59239 - ActiveX control is not registered by installer

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P2)

Description

[Adam Lock]

On Win32, the Mozilla ActiveX control (represented by the DLL mozctl.dll) is not 
registered or configured automatically by the installer. This requires the user 
to perform a manual and error prone configuration.

The control needs to be configured from the installer.

Steps that need to be done:

1. Add the Mozilla binary directory (i.e. the one with mozilla.exe in it) to the 
system's PATH environment variable.
2. Create a registry value in HKEY_LOCAL_MACHINE under "Software\Mozilla", with 
the name "BinDirectoryPath" and the value being the same Mozilla bin directory 
path added to PATH in step 1.
3. Register the control, e.g. by calling "regsvr32 mozctl.dll", or through 
similar means.

Uninstallation requires the PATH & registry entries should be removed.

Comment 1

[Sean Su]

Adam, is it really necessary to add Mozilla's bin dir to the system path?  It is 
possible to have this work without us being in the Path?

Which OS should this be done to, all flavors of Windows?

Comment 2

[Adam Lock]

The ActiveX control is used by EXEs that are typically running from other 
directories, so yes it's necessary to add the Mozilla bin directory to the PATH 
because otherwise Win32 is unable to find the other Mozilla DLLs that the 
control depends on.

Win32 does have something called "Shared DLLs" and it may be possible to avoid 
the PATH requirement if every DLL in the Mozilla bin directory is registered as 
one of these. In theory that means that the system will be able to resolve the 
DLLs that the control depends on. I haven't tried this though.

Comment 3

[Sean Su]

Let me know what you find about the "Shared Dlls".  I'd rather do that than 
touch the Path.

Comment 4

[Adam Lock]

I have written a new DLL called mozctlx.dll that fixes up the paths at runtime 
and instantiates mozctl.dll. If I get this into the build and the install 
scripts it would be necessary to set a key in the registry and register the 
control but all the other path crap & reboots wouldn't be needed anymore.

The new DLL is in mozilla/embedding/browser/activex/src/control_kicker.

Comment 5

[Sean Su]

You will need to make sure that the new file(s) get delivered and installed.
Just make sure that it gets delivered to $DIST and the
...\xpinstall\packager\packages-win is updated to include either the dir of
where the file(s) reside or the file(s) themselves (it sounds like it should be
in the [browser] section).  The installer build process will take care of the rest.

Once the file is being installed, I can update the installer script to set a
registry key and register the new file that needs to be registered.  However,
you will need to provide this info to me.

Comment 6

[Adam Lock]

This bug depends on bug 67682

Comment 7

[Adam Lock]

mozctlx.dll is now in the build and install. There are two things that must now 
be done by the installer:

1. Create a registry entry called "BinDirectoryPath" 
under "HKEY_LOCAL_MACHINE\Software\Mozilla\" which points to the Mozilla bin 
directory.
2. Register mozctlx.dll - e.g. run "regsvr32 mozctlx.dll" or by calling the 
exported method DllRegisterServer directly.

Comment 8

[ajbu]

Is the control always installed in the same bin directory as the Mozilla files?
The dll should probably set this directory itself on registering with
DllRegisterServer. Otherwise look at the registry key
\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Mozilla.exe that already
points to the Mozilla directory. 

Comment 9

[Adam Lock]

I want to put all the PATH fudging into mozctlx.dll. I think it would be 
possible for mozctlx.dll to work without BinDirectoryPath, or only use it as a 
last resort so I intend to get rid of this step.

I'll use bug 71363 to cover the changes to mozctlx to deprecate 
BinDirectoryPath.

Comment 10

[Peter Lubczynski]

Adam is this path thing fixed? It seem to work okay for me in the ActiveX 
control test pad when I manually registered the new control (mozctlx.dll) with 
regsrv32.exe on Windows 2000. I installed a fresh Netscape 6.x build from this 
evening but I do have a debug build as well. 

I'm **REALLY** interested in this making it into mozilla 0.9.1 if all that's 
needed is to update the installer. Nominating. 

This control awsome and it should be registered by default on ALL Windows 
machines!

Comment 11

[Sean Su]

Adam, is all that is needed for this bug is to call "regsvr32 mozctlx.dll"?  How 
does it locate the mozilla.exe/netscp6.exe bin dir?

Comment 12

[Adam Lock]

Yes, all you need to do is run regsvr32 on mozctlx.dll. It's probably best to 
also use the /s switch to make the thing silent.

Mozctlx.dll used to ask where the bin directory was, but nowadays figures it out 
from it's own module path. It's only if you copy to mozctlx.dll to somewhere 
other than the Moz bin dir (which we don't) that it asks the user where to find 
it.

Comment 13

[Sean Su]

Attachment: patch #1

Comment 14

[Sean Su]

Attachment: patch #1 (ns tree)

Comment 15

[Samir Gehani]

r=sgehani for patches 35004 and 35007.

Comment 16

[Daniel Veditz [:dveditz]]

getFolder() now supports files despite the old name. It would be far better to 
do that than the file:/// hack:

 fileMozCtlx = getFolder(fProgram, "mozctlx.dll");

With that change, sr=dveditz 

Comment 17

[Sean Su]

fixed with dveditz's suggestion.

Comment 18

[Grace Bush]

verified - was fixed. changes backed later see bug 81743