Closed Bug 229706 Opened 20 years ago Closed 18 years ago

Unattended install asks for installation folder.

Categories

(Firefox :: Installer, enhancement, P3)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows XP
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: ressu, Assigned: bugs)

References

Details

(Keywords: fixed-aviary1.0.1, helpwanted)

Attachments

(1 file, 2 obsolete files)

Better fix
3.00 KB, patch
bugs
: review+
mkaply
: approval-aviary1.0.1+
Details | Diff | Splinter Review 
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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Blocks: 241532
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..
Flags: blocking-aviary1.0?
*** 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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Keywords: helpwanted
Priority: -- → P3
Target Milestone: --- → After Firefox 1.0
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
Flags: blocking-aviary1.0- → blocking-aviary1.0+
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. )
Flags: blocking-aviary1.0+
Flags: blocking-aviary1.0?
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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** 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'
Attached patch partial patch (obsolete) — — Splinter Review 
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.
Blocks: MSI
Flags: blocking-aviary1.1?
*** Bug 265454 has been marked as a duplicate of this bug. ***
Blocks: 272529
Attached patch Better fix — — Splinter Review 
OK, so here's the patch we are using. This ONLY fixes silent install.
Attachment #166380 - Attachment is obsolete: true
Attachment #168649 - Attachment is obsolete: true
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

[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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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.
Attachment #170820 - Flags: approval-aviary1.0.1?
*** Bug 276982 has been marked as a duplicate of this bug. ***
Comment on attachment 170820 [details] [diff] [review]
Better fix

yes. Definitely.
Attachment #170820 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1+
Flags: blocking-aviary1.1?
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.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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".
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
(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").
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
(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
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
No longer blocks: MSI
You need to log in before you can comment on or make changes to this bug.