Unattended install asks for installation folder.

VERIFIED FIXED in Future

Status

()

enhancement
P3
normal
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: ressu, Assigned: bugs)

Tracking

({fixed-aviary1.0.1, helpwanted})

unspecified
Future
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

Reporter

Description

16 years ago
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
Reporter

Comment 2

16 years ago
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

16 years ago
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

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

Comment 5

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

Comment 6

15 years ago
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

15 years ago
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

Comment 9

15 years ago
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.

Comment 11

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

Comment 12

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

Comment 13

15 years ago
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

15 years ago
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

15 years ago
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.

Comment 17

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

Updated

15 years ago
Flags: blocking-aviary1.0?

Comment 18

15 years ago
*** 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 :(

Comment 20

15 years ago
(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

Comment 22

15 years ago
I can help in testing.

Comment 23

15 years ago
(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

15 years ago
Of course I am able to test this too !

Comment 25

15 years ago
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

15 years ago
this is a problem for mass distrubition
Flags: blocking-aviary1.0- → blocking-aviary1.0+

Comment 27

15 years ago
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+

Updated

15 years ago
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-

Comment 29

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

Comment 30

15 years ago
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

15 years ago
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' 
Posted 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.

Updated

15 years ago
Blocks: MSI

Updated

15 years ago
Flags: blocking-aviary1.1?

Comment 35

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

Updated

15 years ago
Blocks: 272529
Posted patch Better fixSplinter Review
OK, so here's the patch we are using. This ONLY fixes silent install.

Updated

15 years ago
Attachment #166380 - Attachment is obsolete: true
Attachment #168649 - Attachment is obsolete: true

Comment 37

15 years ago
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 39

15 years ago
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

15 years ago
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
Last Resolved: 15 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+

Updated

15 years ago
Flags: blocking-aviary1.1?

Comment 44

15 years ago
This bug apparently didn't land on 1.0.1 yet.

Comment 45

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

Comment 46

15 years ago
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

14 years ago
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

Comment 48

14 years ago
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 → ---

Comment 49

14 years ago
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
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Status: RESOLVED → VERIFIED

Comment 50

14 years ago
(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
Last Resolved: 14 years ago14 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
You need to log in before you can comment on or make changes to this bug.