Closed Bug 1703180 Opened 4 years ago Closed 3 years ago

Optionally detect existing install path for silent install

Categories

(Firefox :: Installer, enhancement, P3)

Product:
Firefox
Component:
Installer
Version:
Firefox 86
Type:
enhancement

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: chengshing.lim, Unassigned, NeedInfo)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

We are upgrade from Firefox 32bit to Firefox 64bit to existing location C:\Program Files (x86)\Mozilla Firefox to avoid new install Firefox create new profile.

Actual results:

After upgrade Firefox 64bit to C:\Program Files (x86)\Mozilla Firefox

When Altiris patch Firefox 64bit using msi, it is install to C:\Program Files\Mozilla Firefox instead of existing Firefox 64bit location C:\Program Files (x86)\Mozilla Firefox

This causing duplicated Firefox 64bit in user computer.

Expected results:

Firefox msi installer should able to detect existing Firefox 64bit install location and install to same location like Google Chrome

The Bugbug bot thinks this bug should belong to the 'Firefox::Installer' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Installer

Since bug 1558320 this works with a non-silent full install, unfortunately the logic for choosing a directory is in LeaveOptionsCommon, so it only runs during a non-silent install.

Until this can be resolved (though we may not want to change this automatically), you could try using INSTALL_DIRECTORY_PATH with the MSI as described in the MSI documentation, for instance:

msiexec.exe /i "Firefox Setup 87.0.msi" INSTALL_DIRECTORY_PATH="C:\Program Files (x86)\Mozilla Firefox"

Altiris should be locating the Firefox install, not assuming where it is. You should opening the bug with them.

(In reply to Mike Kaply [:mkaply] from comment #3)

Altiris should be locating the Firefox install, not assuming where it is. You should opening the bug with them.

I have raise this to Broadcom(Altiris support). Following are the reply from Broadcom

Thank you for your patience. I have analyzed the issue and consulted with my team. So, when you download the exe from the website and run it, it will autodetect the directory and 64bit and update the firefox manually. As you have seen, this is not a silent install and requires end users interaction to begin the upgrade.
In the case of our patch management system, we are detecting that this is 64bit and identifying the directory as well. However, Firefox has provided us anMSI to execute silently and this is where it takes the standard default path to upgrade for 64bit.
This is a vendor issue. You may need to check with Firefox on enterprise upgrading recommendations, especially the path it is installed in. I understand that this is not what you expect as an answer from me, but considering that you are forcefully installing the vendor product in another directory than the standard directory, then this needs to be rectified by the vendor.

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #2)

Since bug 1558320 this works with a non-silent full install, unfortunately the logic for choosing a directory is in LeaveOptionsCommon, so it only runs during a non-silent install.

Until this can be resolved (though we may not want to change this automatically), you could try using INSTALL_DIRECTORY_PATH with the MSI as described in the MSI documentation, for instance:

msiexec.exe /i "Firefox Setup 87.0.msi" INSTALL_DIRECTORY_PATH="C:\Program Files (x86)\Mozilla Firefox"

Hello Adam,
This solution doesn't work in Altiris patch management system, Altiris detecting 64bit and identifying the directory as well. However, Firefox MSI execute silently and this is where it takes the standard default path to upgrade for 64bit. This is what the feedback I got from Altiris support team.

I'm pretty sure the MSI just uses our standard installer so it would put 64 bit Firefox in the 32 bit directory if 32 bit was installed. Confirming with Molly.

Flags: needinfo?(mhowell)

That's correct. There are properties in the MSI that you can set if you need to override the default directory; see the support page for the details.

Flags: needinfo?(mhowell)

Feel free to direct Altiris us directly. If they are using our installers properly, they wouldn't be having this problem.

Hi Mike and Molly,

I support the Altiris Patchmanagement product. I will explain the situation again.

We are using Altiris Patchmanagement to update firefox, and our default command for patch is using the regular logic where firefox 64bit would update on 64bit folder and Firefox 32bit would update on 32bit folder.

Our customer has 64bit installed on some machines on 64bit folder and some machines on 32bit folder. With the current implement patch management, Firefox will only install 64bit update in 64bit folder, and if it detects the 64bit application on 32bit, it will create a new folder in the 64bit folder and thus having 2 different 64bit firefox on one machine.

So, current the challenge for the customer is to have firefox dynamically update for all 32bit and 64bit folders. If this is possible, then please let me know the command option, as I have not seen that defined in your documentation. If I missed it somehow, then please assist in this matter.

Many thanks.
Tony

if it detects the 64bit application on 32bit, it will create a new folder in the 64bit folder and thus having 2 different 64bit firefox on one machine.

This is the part that is not correct. Our installer doesn't work like that. If Firefox is installed in 32 bit, it upgrades into with 64 bit. We don't put a new version of Firefox in a different directory.

This makes me think you are not using the default installer directly.

With the MSI, it does behave like this. The customer and myself have tried this and we both have had the same results.
With EXE, it requires UI interaction to click on next and this detects the correct directory and upgrades.
Many thanks
Anthony

(In reply to Mike Kaply [:mkaply] from comment #10)

If Firefox is installed in 32 bit, it upgrades into with 64 bit. We don't put a new version of Firefox in a different directory.

As I said in comment 2, this does not apply to silent installers. We do always try to use an existing install path, but that comes after we've set the registry view (the installer is 32-bit natively, SetRegView 64 switches to the 64-bit view for 64-bit builds). For an All Users (system-wide) install, this means a 32-bit and 64-bit MSI or silent install won't find each other [1] [2]. This is only overcome on non-silent installs, see comment 2.

I've confirmed this by installing a 32-bit MSI as admin followed by a 64-bit MSI install as admin, with no args, the result is two installs.

I'm reluctant to make any changes here, as the administrator can specify an install directory with INSTALL_DIRECTORY_PATH. Any change in this default behavior will probably break some other setups relying on the current behavior. On the other hand it is inconsistent with the non-silent install. We might add a switch? Or maybe it's better to consistently find the other arch?

(Sorry for the delay in clarifying, I thought I had submitted this yesterday.)

[1] A Current User install will be fine, as HKCU\SOFTWARE is shared, while HKLM\SOFTWARE is not, see ref.

[2] There's also the stub, it will use an existing install path because of this logic, and the old 32-bit registry keys will be cleaned up by RegCleanMain and RegCleanUninstall.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox msi is always install to C:\Program Files\Mozilla Firefox → Silent 32-bit install doesn't replace existing 64-bit install
Summary: Silent 32-bit install doesn't replace existing 64-bit install → Silent 64-bit install doesn't replace existing 32-bit install

Just for clarification I will put questions below and I would appreciate if someone can respond to each of the questions.

  • Our Patch management system uses MSI to upgrade either 32bit or 64bit application in 32bit directory and 64bit directory respectively without any issues. Is that understood?

  • Customer has installed 64bit Firefox in 32bit directory (some machines), and 64bit Firefox in 64bit directory (Some machines), and they would like to have both these scenarios to be patched with the Auto silent update. In my opinion, this seems to be a Mozilla bug, as if I am not mistaken 67 version used to work without any issues. Please clarify this answer for me if you accept this as a bug.

  • Current MSI only upgrades 64bit Firefox in 32bit Directory, if we use the INSTALL_DIRECTORY_PATH switch with MSI. But what would happen to the 64bit Firefox in 64bit directory?

  • IMO, this would become a very complex deployment to upgrade an environment with 150 000+ machines. Would you agree?

Please advise.

Thank you

(In reply to Anthony D from comment #13)

  • Our Patch management system uses MSI to upgrade either 32bit or 64bit application in 32bit directory and 64bit directory respectively without any issues. Is that understood?

Yes.

  • Customer has installed 64bit Firefox in 32bit directory (some machines), and 64bit Firefox in 64bit directory (Some machines), and they would like to have both these scenarios to be patched with the Auto silent update. In my opinion, this seems to be a Mozilla bug, as if I am not mistaken 67 version used to work without any issues. Please clarify this answer for me if you accept this as a bug.

I tried with 67.0 (win32 MSI, win64 MSI), it seems to have the same behavior, 64-bit does not overwrite 32-bit.

Moreover, I was wrong when I said above that this was an oversight in bug 1558320, this goes beyond 64-bit and 32-bit. It has always been the case that silent installs do not try to discover the location of a previous install. The code I called out in comment 12 is just for telemetry, it doesn't use the path that it finds.

  • Current MSI only upgrades 64bit Firefox in 32bit Directory, if we use the INSTALL_DIRECTORY_PATH switch with MSI. But what would happen to the 64bit Firefox in 64bit directory?

  • IMO, this would become a very complex deployment to upgrade an environment with 150 000+ machines. Would you agree?

Are the deployment tools able to set INSTALL_DIRECTORY_PATH to a existing 32-bit path if it exists?

I've changed the summary to clarify this would be about adding a general option.

Summary: Silent 64-bit install doesn't replace existing 32-bit install → Optionally detect existing install path for silent install

Hi Adam,
Apologies for my delayed response

Are the deployment tools able to set INSTALL_DIRECTORY_PATH to a existing 32-bit path if it exists?
Anthony - yes, it is possible., but the problem is customer has few machines in the -32bit directory and some -64bit directory.

Can you please advise your standard practice to any corporates?

Thank you.
Best regards,
Anthony

(In reply to Anthony D from comment #15)

Can you please advise your standard practice to any corporates?

Hi Anthony. I'd like to help you out here, but I'm not entirely sure what you are asking. Could you clarify your question? Thanks!

Flags: needinfo?(anthony.dsouza)
Priority: -- → P3

(In reply to Anthony D from comment #15)

Hi Adam,
Apologies for my delayed response

Are the deployment tools able to set INSTALL_DIRECTORY_PATH to a existing 32-bit path if it exists?
Anthony - yes, it is possible., but the problem is customer has few machines in the -32bit directory and some -64bit directory.

Can you please advise your standard practice to any corporates?

I'm not familiar with what's possible and not with Altiris, but my suggestion would be to either:
a) Do what Adam suggested in comment #14, and set INSTALL_DIRECTORY_PATH in the one case where it's necessary.
or
b) Always set INSTALL_DIRECTORY_PATH, and adjust the value based on some properties of the system (if this is possible with Altiris).

Chengshing or Anthony, do either of these ideas help?

Severity: -- → S3
Flags: needinfo?(chengshing.lim)

No replies for needinfo requests from reporters, marking as Resolved: Incomplete, bug can be reopened if the situation changes.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.