Open Bug 1062637 Opened 10 years ago Updated 2 years ago

Firefox silent install does not maintain non-default install location

Categories

(Firefox :: Installer, enhancement, P5)

32 Branch
x86_64
Windows 8.1
enhancement

Tracking

()

REOPENED

People

(Reporter: u498376, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36 Steps to reproduce: 1. Install a previous version of Firefox (ie 29) to a non-default location (ie C:\MyFireFox\) 2. Run latest Firefox installer (ie 32) using the following silent flag: /S We are using System Center 2012 Configuration Manager and many systems have various custom locations and we do not wnat ot have to figure out which ones are where and create special collection and deployments to use the ini file to control this just to work around this installer bug. Just about every installer for the other products we use silent installs for seem to find the current install in the registry (that they created during the previous install of the application) and then update that version. Basically I would think the installer would check HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\CurrentVersion to find the last/current installed version then use that result to go to HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\<version (lang)>\Main\Install Directory to get the current install directory to upgrade. We have noticed this on all the versions going back at least version 26 but may be in all versions of the installer using the silent flag. Actual results: It installed a new version of 32 to into the default location and left 29 in its custom location leaving me with two different versions installed on the system. Expected results: Should have upgraded version 29 to 32 leaving it in its original non-default installed location of C:\MyFireFox\
BTW when you use the GUI installer select "Standard" it uses the location for non-defaults install just fine, so this seems to be a bug in the silent since it is not following the same logic as a "Standard" aka "Default" install.
Component: Untriaged → Installer
The silent install option intentionally uses only default setting hence why it uses the default install location vs. a custom install location from a previous install. This is due to the additional code complexity required. If you want to use a specific install location and use silent install you must use the /INI method.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
I would argue that the "Standard" option is the "Default" path for the installer and what "Standard" does the Silent installer should do. I stated why we can't use the INI method and why your installer is not following typical best practices for silent installs. INI method requires you to know where it is installed at the time, and using SCUP and SCCM you can't do that and your installer already has a "Standard" path that is its "Default" path in the UI mode and that path is what a silent install would be expected to follow. If you are unwilling to following typical best practices for silent installs how about create a new switch in the installer that combined with /S will do the standard path, like "/S /Standard" or something if you refuse to think of your standard option as your default (which is is selected by default which technically makes it your default path). I urge you to be more open minded about this and think about your enterprise customers who are using product, and trying to support thousands if not 10's of thousands of endpoints that have your products installed. Please reopen this and address it as either a bug fix for the silent install or a feature request for a new command line switch to use with the silent switch.
Flags: needinfo?(robert.strong.bugs)
Sounds like a very unmanaged environment that you are trying to manage! btw: this has always been the case for the installer https://wiki.mozilla.org/Installer:Command_Line_Arguments "Silent install (always installs into the default location. Use the "Configuration ini file" option below to set the install location and other install options)" so changing to enhancement. I'm ok with adding this as long as it doesn't impact code complexity. Also, if there is more than one install there is no way to determine which install location to use and it will then fallback to the default install location. Also, there is a ton of other current and planned work that has a much higher priority than adding this feature request.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(robert.strong.bugs)
Resolution: WONTFIX → ---
Its not a matter of managed vs unmanaged, its a matter of large enterprise that grew from separate departments and having lots of rules for each of them. Developers vs, Sales vs Accounting, etc. This is common in many large enterprises that have grown from smaller company mergers and departmental changes and requirements. Remember this is not a SILENT INSTALL really this is a SILENT UPGRADE that I am talking about. I would assume that the goal is to make sure we upgrading the version that is installed and not ignoring it with a silent upgrade. I understand and have read that document about command line arguments and I would argue that that is not common best practices for silent upgrades (but is for silent first time installs), and that you documentation is all about installs and does not seem to take into account or consider silent upgrades which could be considered a design bug if you want. As to the multiple installed versions this is easy you only update the last installed version which is easy to detect via the registry entries you lay down. So last one wins in this case of an silent install, which is also what the "Standard" option appears to do in the UI mode update. Because if they have 3 different versions installed into 3 different non-default locations do you really think the expectation is to install a new 4th version into the default location. I think the safest approach is to upgrade the last installed version, or throw an error and not allow silent upgrades when more than on version of FF is installed into different locations. In these situations of multi installed FF versions they are rare especially on windows and while we do not have any of these in any of our environments I would assume that these are special cases where I need have special handling for and that is where the INI file would shine is in these multiple installed locations for multiple version, however the INI file should be needed in a single install is in the box in a large majority of cases. I appreciate it be reopened thank you. I personally think this is a bug in the silent installer by defined that silent install should do the default options in the UI install which in Firefox's case is the the Standard option which updates the last installed version even if it was a non-default installation location. I look forward to see this appear in a future version as it will make Enterprise deployments much easier, safer and secure. Thanks again!!
On the surface I agree with you but unlike most other Windows applications which include the ones that support installing into the previously installed to directory we have a requirement to support multiple installations of the same application which makes installing into the directory you want it to much more difficult as I noted in comment #4 in that it will need to install into the default directory when there are more than one installation of the application. Hence, I just punted on adding this for the silent install code path especially since this is by far not needed for the vast majority of users. I also added the silent installation capability on my personal time since it was not considered as high of a priority as other work and I see significant value in having this capability.
In the case of multiple installed versions I think it would be better to have a silent upgrade fail with an error code than have it go from upgrade to full install of a another instance of FF into the default install location. As a large enterprise admin type of person, personally, I think that if you are going to support multiple versions of FF instances installed on the same system all of which are in custom installed location then you should not be using the standard silent upgrade process, that this is a great case for using the INI option. I personally think it safer to error in that situation that to install a another copy as that would not be the expected behavior by an admin my experience as I am talking only the the case of PATCHING via a SILENT UPGRADE. I really appreciate all the work you have done on the silent installation feature. I only wish to help improve the silent upgrade functionality of it to allow for easier, safer, and more secure silent upgrades of FF in the most common Enterprise situations. Thanks!
We really aren't going to spend a lot of time for this edgecase use case when there is to say the least plenty of work that needs to be done that applies to the majority of our users. That isn't to say that we wouldn't accept a patch that accomplishes what you are suggesting.
Just setting the priority field to reflect what comment 8 says.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.