MSI should install into existing Firefox install directory
Categories
(Firefox :: Installer, defect, P3)
Tracking
()
People
(Reporter: mkaply, Unassigned)
References
Details
(Whiteboard: [fidedi-ope])
Currently if you install the Firefox 32 bit MSI and then the 64 bit MSI, they are put in separate directories.
The MSI should honor an existing Firefox install and overwrite it.
This is consistent with how other browsers work (I tried Chrome and I was told Edge does the same)
|
||
Comment 1•1 year ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #0)
The MSI should honor an existing Firefox install and overwrite it.
My understanding is that this is the expected (default) behavior for the full installer and therefore it seems like it also should be for the MSI. Have you checked what happens using full installers instead of MSIs?
|
Reporter | |
Comment 2•1 year ago
|
||
Full installers work fine. This only happens with the MSI. Per Nick:
When I look at this nonsense, it sure looks like the MSI layer decides the directory name and not the installer: https://searchfox.org/mozilla-central/source/browser/installer/windows/msi/installer.wxs
And that directory name is based on the architecture of the MSI. I’m not sure that can be addressed with the WIX packaging layer.
|
||
Comment 3•1 year ago
|
||
The "nonsense" (hey I wrote that, go easy) in the Wix file will only override the install path if the MSI file itself (or an accompanying transform) were configured to do that by whoever is deploying it. Otherwise the command line parameter is left off.
The NSIS that's used to find the existing install path is this thing; it's invoked from here. I don't immediately see anything wrong with any of this stuff that seems like it should work in the EXE but not the MSI, but clearly there must be something.
I have two thoughts. One, maybe the logic in installer.nsi should be getting run for both SetRegView 32 and SetRegView 64, regardless of what the build being installed is. I don't know why that would cause different behavior in the two execution contexts, but it seems odd. Two, if that doesn't help, use Process Monitor to see what registry values the MSI is trying to read that are apparently not the right ones. That should point you toward a better diagnosis.
|
||
Comment 4•1 year ago
|
||
(In reply to Molly Howell (she/her) (mostly inactive) from comment #3)
The "nonsense" (hey I wrote that, go easy) in the Wix file will only override the install path if the MSI file itself (or an accompanying transform) were configured to do that by whoever is deploying it. Otherwise the command line parameter is left off.
Molly! I see that "(mostly inactive)" is correct and appreciate it. No offense intended, I perpetrate my own share of nonsense every day :)
Thank you for clarifying.
The NSIS that's used to find the existing install path is this thing; it's invoked from here. I don't immediately see anything wrong with any of this stuff that seems like it should work in the EXE but not the MSI, but clearly there must be something.
I have two thoughts. One, maybe the logic in
installer.nsishould be getting run for bothSetRegView 32andSetRegView 64, regardless of what the build being installed is. I don't know why that would cause different behavior in the two execution contexts, but it seems odd. Two, if that doesn't help, use Process Monitor to see what registry values the MSI is trying to read that are apparently not the right ones. That should point you toward a better diagnosis.
Thanks for the suggestions, we'll try to run this down.
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
||
Comment 5•1 year ago
|
||
small addition... regardless of using the MSI or exe-installation source when installing silently with the "InstallDirectoryPath"-switch pointing to the x86 directory of ESR 118 x86 there is some weird mess up. ESR 115 x86 is still under x86 program files, no ESR128 x64 installation under x64 program files, the listing in start menu is faulty and in Windows list of installed software you can find both versions (x64 looks faulty)
|
|
||
Comment 6•1 year ago
|
||
may I ask if there is already a timeframe for correction?
Because there is demand for ESR128 we have to decide to wait for a fix of x64 or to go with x86 till the next major version drops.
|
|
||
Comment 7•11 months ago
|
||
(In reply to pascal.michaelis from comment #6)
may I ask if there is already a timeframe for correction?
Since this is marked S3, it no assignee, and I don't know of any way it impacts the greater projects that our team is currently working on, I'm going to go ahead and say that the timeframe is "not anytime soon".
Description
•