User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ When the installed is invoked with -ma -ira flags (the same flags as suite installer) The installer asks for the folder location to install firebird to. The screen that appears is not the same screen as the folder location in the installer without unattended mode. Reproducible: Always Steps to Reproduce: 1. Download installer from mozilla.org 2. run FirebirdSetup.exe -ma -ira Actual Results: The installer asks for a location where to install the application. Only functional button is cancel. Expected Results: Firebird should have been installed to default location. There is an existing installation of Firebird on my machine, but i doubt that makes a difference.

Confirming, making an enhancement. Though this wouldn't be a bad idea, I'm not sure how likely it is to be implemented, as the vast majority of the users Mozilla Firebird targets won't know or ever use such command line options. (The only command line option I know of for Mozilla Firebird is for the Profile Manager. We still have profiles only accessible through the command line, but it would appear that's being worked on in bug 214675.) My personal thought is WONTFIX as there are other more generally useful bugs to fix, but I'm not in charge of development.

I think this might be trivial to fix, the screen that comes up, looks like the screen that appears with Suite installation. so i think it is just a leftover from the old installation, and the functions need to be adjusted to the current installation process. Also, this is useful for unattended installations, although it is quite simple to drop the unzipped tree to the HD and then throw a link to the desktop. Even still, This is more elegant and has market value ;)

I operate student computer sites (~400 workstations) that uses Firebird and would like to upgrade to Firefox. We use NetInstall to install applications in the background. It does support 'snapshot' style installs when needed, but I would REALLY prefer to do this with an installer. Any hope on getting this fixed soon?

*** Bug 240634 has been marked as a duplicate of this bug. ***

*** Bug 246075 has been marked as a duplicate of this bug. ***

You don't need the command line options, you can also use the config.ini to see the same result, and get slightly finer grained control of the behavior. See bug #246075 (which was closed and marked as duplicate of this bug.) This bug kills all bundled meta-installers on Windows (like student connectivity packages) who want the user to have a similar experience with all of the installed software, as well as writing in the correct uninstallation information to the Windows registry.

I would like to deploy Firefox sitewide at a 400-workstation institution. Without an unattended installation, this is not likely to happen. Extracting both Mozilla 1.7's and Firefox 0.9's setup executables (by running them and snagging the directories from %TEMP%) allowed me to copy Mozilla's setup.exe over Firefox's, and it now runs in unattended mode, albeit with a lot of strange screen refreshes. Very, very kludgey, but less kludgey than writing an AutoIt script.

I'm adding this as a dependency for a Firefox 1.0 widescale deployment meta bug so it gets attention. Incidentally, would any of these problems be solved if Firefox were also packageable as an MSI? That's bug 231062.

Yes, if a MSI would be available, then it would solve this problem. Deploying Thunderbird/Firefox in a network with more than 10-20 systems is a important thing.

IMO, this is not an "enhancement", it is a bug. Unattended installation is a requirement for any non-toy deployment. And the "-ma -ira" switches already work for Mozilla 1.x. An MSI package would be ideal, but any unattended installation mechanism is better than none.

*** Bug 258903 has been marked as a duplicate of this bug. ***

*** Bug 259630 has been marked as a duplicate of this bug. ***

I'm going to disagree with the assignment of this bug to "enhancement" status. The command-line option is already available in the installer's help window (type "setup.exe -h", see http://www.barowy.net/firefox for a screenshot), which leads the user into believing that this functionality is *already present*, and running the program with the option does something different than running it without, which means that the option is currently broken. The hooks for the option are already in there somewhere. IMHO, calling a feature that appears already to exist an "enhancement" is just wrong. If you really want us to plough through the config.ini file (which I'll do; I have no choice), then you should probably remove the reference to silent installs in the help menu. As mentioned many times before, this type of functionality would make doing corporate workstation installs much easier. I can't think of a better way to make Firefox's user base grow.

I hope they fix this bug for the final 1.0 version !! It is very annoying to deploy Firefox on systems currently (especially if you want uninstall info etc. to be added to registry) and fixing this bug would certainly help spread Firefox !

I can only second that this is a very important feature, if we target installations in the enterprises. And when firefox is used in enterprises it will also spread to the private pc's. André

In case my comment from July was unclear... The Mozilla installer works; running "mozilla-win32-1.7.3-installer.exe -ma -ira" performs a silent install. The Firefox behavior is a clear step backward. Software which cannot install silently looks like a toy, not a serious application. This should be treated as a stop-ship bug.

I agree - it should block the 1.0 release. Maybe more people need to vote for this bug so that its gets noticed..

*** Bug 260973 has been marked as a duplicate of this bug. ***

(In reply to comment #6) > You don't need the command line options, you can also use the config.ini to see > the same result Changing the run mode to "Silent" in the config.ini file didn't function - the problem is the same as by using "Firefox.exe -ma -ira" - the installer asks for the installation folder :(

(In reply to comment #19) > (In reply to comment #6) > > You don't need the command line options, you can also use the config.ini to see > > the same result > > Changing the run mode to "Silent" in the config.ini file didn't function - the > problem is the same as by using "Firefox.exe -ma -ira" - the installer asks for > the installation folder :( That was my point. The config.ini gives the same result (i.e. doesn't work.)

silent install is not really something we've tested or planned to test before oct. helpwanted.

I can help in testing.

(In reply to comment #21) > silent install is not really something we've tested or planned to test before > oct. helpwanted. I quite happy to help in testing as well.

Of course I am able to test this too !

From what I see in the installer code, switch(sgProduct.mode) at http://lxr.mozilla.org/aviarybranch/source/toolkit/mozapps/installer/windows/wizard/setup/extra.c#7678 needs to hide couple more setup dialogs: diSelectInstallPath.bShowDialog = FALSE; diUpgrade.bShowDialog = FALSE; I'm not sure if diDownloading, diInstalling and diInstallSuccessful need to be hidden as well.

this is a problem for mass distrubition

Only aviary peers can set blocking +/- flags.. Everybody else should nominate ? the flag for a peer ro grant or deny. :-) (This is also the 4th abuse of this privledge in 5 minutes or so. )

The bug was explicitly marked as *not* blocking 1.0 by Ben Goodger (see View Bug Activity), so *don't* change the flag to re-request blocking.

*** Bug 269971 has been marked as a duplicate of this bug. ***

We push firefox out to every pc as a security measure at work, and this is making it much more of an ordeal than it should be. It works when you use the firefox install files with Mozilla's setup.exe and the -ms -ira flags, I think you'll be more likely to grab chunks of marketshare if more corporations push it.

If you want this deployed on a lot of machines - the silent install must be fixed. I don't want to spend hours getting this to work to roll it out onto 400 computers.

(In reply to comment #25) > From what I see in the installer code, switch(sgProduct.mode) at > http://lxr.mozilla.org/aviarybranch/source/toolkit/mozapps/installer/windows/wizard/setup/extra.c#7678 > needs to hide couple more setup dialogs: > > diSelectInstallPath.bShowDialog = FALSE; > diUpgrade.bShowDialog = FALSE; > > I'm not sure if diDownloading, diInstalling and diInstallSuccessful need to be > hidden as well. Yes, I noticed this as well. All of those listed should be added to that code, except for diInstallSuccessful. The function for displaying the 'Install Successful'

Sorry for that last comment... As Walter saw, there were some missing dialogs in the bit of code that deals with 'Auto' and 'Silent' installs. However, you cannot add diInstallSuccessful to that list. It seems that the function that displays that dialog also does some bit of work when you click on the Finish button. If you don't show that dialog, then that code doesn't get run, and the install just hangs. I'm not sure how to handle this, though. The 'finish' work should probably be separated from that dialog function. Any ideas how to best do this?

Here's more info. Essentially, these dialogs are never told not to display if we are silent, so I added that. Unfortunately, the install never kicks if these dialogs aren't there, so I added that. This makes silent install work. Auto install kind of works. The dialog doesn't close at the end. I'm working on that.

*** Bug 265454 has been marked as a duplicate of this bug. ***

OK, so here's the patch we are using. This ONLY fixes silent install.

I think we should land this patch on the trunk when we open the tree back up after 1.8a6. Fixing the installer's silent mode will leave us in a better position than we are now.

Comment on attachment 170820 [details] [diff] [review] Better fix r=ben@mozilla.org

Comment on attachment 170820 [details] [diff] [review] Better fix [cmp@spruce setup]$ cvs commit Checking in dialogs.c; /cvsroot/mozilla/toolkit/mozapps/installer/windows/wizard/setup/dialogs.c,v <-- dialogs.c new revision: 1.27; previous revision: 1.26 done Checking in extra.c; /cvsroot/mozilla/toolkit/mozapps/installer/windows/wizard/setup/extra.c,v <-- extra.c new revision: 1.15; previous revision: 1.14 done

Thunderbird now installs completely when using the MSI package and silent installer mode. Marking this bug resolved. Please file any automated installer issues you find in a new bug.

Comment on attachment 170820 [details] [diff] [review] Better fix Should this be back-ported for any 1.0.1 release? Outside the scope of a security firedrill, but if it's a more general bugfix release this might be appropriate and helpful. Patch doesn't touch code for Firefox itself.

*** Bug 276982 has been marked as a duplicate of this bug. ***

Comment on attachment 170820 [details] [diff] [review] Better fix yes. Definitely.

This bug apparently didn't land on 1.0.1 yet.

I've got this (and my other patches) scheduled for this weekend.

Comment on attachment 170820 [details] [diff] [review] Better fix Landed on the Aviary 1.0.1 branch: Checking in dialogs.c; /cvsroot/mozilla/toolkit/mozapps/installer/windows/wizard/setup/dialogs.c,v <-- dialogs.c new revision: 1.22.2.1.4.4.2.1; previous revision: 1.22.2.1.4.4 done Checking in extra.c; /cvsroot/mozilla/toolkit/mozapps/installer/windows/wizard/setup/extra.c,v <-- extra.c new revision: 1.10.6.4.2.1; previous revision: 1.10.6.4 done

Reopening. It appears that the main problem here has been fixed (with today's Firefox 1.0.1 installer, I am able to kick off the install from the command line using -ma -ira without being prompted for an install directory and the build works), but the Install dialog never goes away...instead the dialog just sits there after it has completed installing at the "installing Firefox Help" step. If this is something that can be fixed quickly, let's try to get it in for 1.0.1, otherwise we can mark this fixed again and I can create a new bug for the remaining issue.

Reopening. It appears that the main problem here has been fixed (with today's Firefox 1.0.1 installer, I am able to kick off the install from the command line using -ma -ira without being prompted for an install directory and the build works), but the Install dialog never goes away...instead the dialog just sits there after it has completed installing at the "installing Firefox Help" step. If this is something that can be fixed quickly, let's try to get it in for 1.0.1, otherwise we can mark this fixed again and I can create a new bug for the remaining issue.

Marking this Verified Fixed. After talking to Chase, I learned that this works as intended by mkaply when you run the installer in silent mode with "-ms".

(In reply to comment #47) > Reopening. ... > If this is something that can be fixed quickly, let's try to get it in for > 1.0.1, otherwise we can mark this fixed again and I can create a new bug for the > remaining issue. Which remaining issue?

I have to reopen the bug. Today I tried to install Firefox 1.0.3 on 20 machines. The unattended install doesn't finish. Like Jay already mentioned, the installation dialog stays open after the installation of the help or QFA. Shortcuts are sometimes created and sometimes not. Also no uninstall information is written. It happens when using the "-ma -ms" switches. Additionally I found another interesting part: Starting the installer with "-mac -ms" doesn't show any dialog. The whole installation runs in the background. I didn't see it as a bug but as a enhancement. The option "mac" is nowhere listed. It's strange but with this options the installation finishes. The issues mentioned above don't appear. All parts were installed fine. This should also happen for the standard way ("-ma -ms").

I think you are a little confused on the switches. There are two switches, /ma and /ms and they are mutually exclusive. /ms is the silent install (no dialogs at all) and this works on the 1.0.X branch. /ma is the auto install and this does NOT work on the 1.0.X branch. when you used -ma -ms, you invoked the broken auto installer because we used the first flag we came to. When you used -mac -ms, you used the silent installer because -mac is an invalid flag and we ignored it. If you found documentation on mozilla.org that said to use -ma and -ms together, please let me know and and I will fix it.

(In reply to comment #52) > when you used -ma -ms, you invoked the broken auto installer because we used > the first flag we came to. Ok, that was my fault. Thank you for explanation. It is working graceful. v