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.
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
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.
Let me know what you find about the "Shared Dlls". I'd rather do that than touch the Path.
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.
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.
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.
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.
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.
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!
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?
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.
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
fixed with dveditz's suggestion.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified - was fixed. changes backed later see bug 81743
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.