ActiveX control is not registered by installer

VERIFIED FIXED

Status

P2
normal
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: adamlock, Assigned: ssu0262)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Assignee)

Comment 1

18 years ago
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?
Status: NEW → ASSIGNED
Priority: P3 → P2
(Reporter)

Comment 2

18 years ago
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.
(Assignee)

Comment 3

18 years ago
Let me know what you find about the "Shared Dlls".  I'd rather do that than 
touch the Path.
(Reporter)

Comment 4

18 years ago
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.
(Assignee)

Comment 5

18 years ago
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.
(Reporter)

Comment 6

18 years ago
This bug depends on bug 67682
Depends on: 67682
(Reporter)

Comment 7

18 years ago
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

18 years ago
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. 
(Reporter)

Comment 9

18 years ago
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

18 years ago
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!
Keywords: mozilla0.9.1
(Assignee)

Comment 11

18 years ago
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?
(Reporter)

Comment 12

18 years ago
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.
(Assignee)

Comment 13

18 years ago
Created attachment 35004 [details] [diff] [review]
patch #1
(Assignee)

Comment 14

18 years ago
Created attachment 35007 [details] [diff] [review]
patch #1 (ns tree)

Comment 15

18 years ago
r=sgehani for patches 35004 and 35007.
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 
(Assignee)

Comment 17

18 years ago
fixed with dveditz's suggestion.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 18

17 years ago
verified - was fixed. changes backed later see bug 81743
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.