229706 - Unattended install asks for installation folder.

Status: VERIFIED FIXED

(Firefox :: Installer, enhancement, P3)

Description

[Sami Haahtinen]

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.

Comment 1

[Jeff Walden [:Waldo]]

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.

Comment 2

[Sami Haahtinen]

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 ;)

Comment 3

[Corey Betka]

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?

Comment 4

[Bill Mason]

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

Comment 5

[Bill Mason]

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

Comment 6

[Kurtis McCathern]

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.

Comment 7

[Chris Combs]

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.

Comment 8

[Jeff Walden [:Waldo]]

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.

Comment 9

[André Schild]

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.

Comment 10

[Patrick J. LoPresti]

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.

Comment 11

[Bill Mason]

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

Comment 12

[Bill Mason]

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

Comment 13

[Daniel Barowy]

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.

Comment 14

[Alexander]

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 !

Comment 15

[André Schild]

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é

Comment 16

[Patrick J. LoPresti]

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.

Comment 17

[Ken Johanson]

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

Comment 18

[Bill Mason]

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

Comment 19

[Adrian Kalla [:adriank]]

(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 :(

Comment 20

[Kurtis McCathern]

(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.)

Comment 21

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 22

[André Schild]

I can help in testing.

Comment 23

[Daniel Barowy]

(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.

Comment 24

[Alexander]

Of course I am able to test this too !

Comment 25

[Walter K.]

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.

Comment 26

[Fareed Rizkalla]

this is a problem for mass distrubition

Comment 27

[Wolf [:wolf]]

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. )

Comment 28

[Jeff Walden [:Waldo]]

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.

Comment 29

[Bill Mason]

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

Comment 30

[Sean]

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.  

Comment 31

[Michael Gorn]

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.

Comment 32

[jhp (no longer active)]

(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' 

Comment 33

[jhp (no longer active)]

Attachment: partial patch

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?

Comment 34

[Mike Kaply [:mkaply]]

Attachment: Patch that somewhat fixes the problem.

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.

Comment 35

[Doug Wright]

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

Comment 36

[Mike Kaply [:mkaply]]

Attachment: Better fix

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

Comment 37

[Chase Phillips]

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 38

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 170820 [details] [diff] [review]
Better fix

r=[e-mail]

Comment 39

[Chase Phillips]

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

Comment 40

[Chase Phillips]

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 41

[Daniel Veditz [:dveditz]]

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.

Comment 42

[Daniel Veditz [:dveditz]]

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

Comment 43

[Mike Kaply [:mkaply]]

Comment on attachment 170820 [details] [diff] [review]
Better fix

yes. Definitely.

Comment 44

[Axel Hecht]

This bug apparently didn't land on 1.0.1 yet.

Comment 45

[Chase Phillips]

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

Comment 46

[Chase Phillips]

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

Comment 47

[Jay Patel [:jay]]

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.

Comment 48

[Jay Patel [:jay]]

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.

Comment 49

[Jay Patel [:jay]]

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".

Comment 50

[Worcester12345]

(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?

Comment 51

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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").

Comment 52

[Mike Kaply [:mkaply]]

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.

Comment 53

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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