Bug 231062 (MSI)

Provide Firefox MSI package

RESOLVED WONTFIX

Status

()

Firefox
Installer
--
enhancement
RESOLVED WONTFIX
14 years ago
12 days ago

People

(Reporter: alanjstr, Unassigned)

Tracking

(Depends on: 5 bugs, Blocks: 7 bugs)

Trunk
Future
x86
Windows 2000
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.8b5 -
blocking-firefox3 -
blocking-firefox3.6 -
blocking-firefox2 -

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(22 attachments, 35 obsolete attachments)

7.60 KB, patch
jimm
: review+
Details | Diff | Splinter Review
10.07 KB, patch
rstrong
: review+
Details | Diff | Splinter Review
8.71 KB, patch
jimm
: review+
Details | Diff | Splinter Review
4.43 KB, patch
rstrong
: review+
Details | Diff | Splinter Review
413 bytes, patch
rstrong
: review+
Details | Diff | Splinter Review
871 bytes, patch
jimm
: review+
Details | Diff | Splinter Review
9.31 KB, patch
jimm
: review+
Details | Diff | Splinter Review
1.75 KB, patch
jimm
: review+
Details | Diff | Splinter Review
4.25 KB, patch
jimm
: review+
Details | Diff | Splinter Review
746 bytes, patch
jimm
: review+
Details | Diff | Splinter Review
4.48 KB, patch
ted
: review+
Pike
: feedback+
Details | Diff | Splinter Review
9.96 KB, patch
Mitch
: review+
Details | Diff | Splinter Review
4.80 KB, patch
khuey
: review+
Details | Diff | Splinter Review
6.27 KB, patch
Mitch
: review+
Details | Diff | Splinter Review
6.68 KB, patch
Mitch
: review+
Details | Diff | Splinter Review
10.64 KB, patch
Mitch
: review+
Details | Diff | Splinter Review
1.17 KB, patch
jimm
: review+
Details | Diff | Splinter Review
7.20 KB, patch
jimm
: review+
Details | Diff | Splinter Review
6.40 KB, patch
jimm
: review+
Details | Diff | Splinter Review
14.79 KB, patch
Details | Diff | Splinter Review
4.54 KB, patch
Details | Diff | Splinter Review
7.63 KB, application/xml
Details
(Reporter)

Description

14 years ago
Bug 52052 was for Seamonkey and WONTFIX'd.  There are lots of good reasons to
use .msi on Win32, including corporate deployment.

This would also ease an upgrade path, uninstallation, selecting shortcut
locations, and maybe even file associations.
(Reporter)

Comment 1

14 years ago
An alternative is to use NSIS (see http://seb.mozdev.org/firebird/ ).  Either
would allow a net-installer.
(Reporter)

Comment 2

14 years ago
See also http://www.installsite.org/pages/en/msi/authoring.htm
(Reporter)

Comment 3

14 years ago
We should ask apache.org how they do it
(Reporter)

Comment 4

14 years ago
IRC discussion:

http://www.pseudorandom.org/irclog/mozilla/%23mozilla/%23mozilla.2004-01/%23mozilla.2004-01-15.log
(Reporter)

Comment 5

14 years ago
Discussion starts at 
23:00 < alanjstr> anyone know anything about making .msi files?

Comment 6

14 years ago
I think we need to implement this on Windows, because with newer MS compilers
the C/C++ runtimes are no longer system files and have to be distributed with
the application. This means that in the long term, when we move away from VC6
we're going to run into a chicken and egg problem, as the current installer
won't run without the C/C++ runtimes.

IMO, this is something that we'll probably *have* to do in the long term.

Comment 7

14 years ago
The fact that installing software across Active Directory (Microsofts domain
technology) requires MSI's, makes me think that this is quite an important thing
to have done. It makes pushing out software to users (100s or 1000s) extremely easy.
Summary: Firebird installer for Windows should use the MSI (Microsoft Installer) → Firefox installer for Windows should use the MSI (Microsoft Installer)

Comment 8

13 years ago
The wontfix on bug 52052 in part explains why NS7.1 never got installed in our
building: computing support people don't necessarily have any interest in
browsing functionality beyond "good enough" for normal users.  Combined with
disinterest among administrators and managers, and you get software stasis. 
Making software distribution easy and automatable for support folk is nearly
essential, and in a Windows environment, that means MSI.

Updated

13 years ago
Blocks: 241532
http://sourceforge.net/projects/wix/

Perhaps WiX would be a good way to do this?  I'm not sure how much its status as
CPL matters, if any (it looks like the CPL only applies to distribution of code,
not product use).  It would seem to be a good way to go, as it's been used
before by Microsoft and has command line tools that would fit into the command
line based build process the Mozilla tree uses.  (I haven't worked with it,
tested it, or gone much beyond reading the blurb about it on the WiX site, so I
might be wrong about its utility for this bug.)

Comment 10

13 years ago
An MSI package would be very helpful for administrators, as it simplifies the
software installation process for thousands of machines to a couple minutes
(stick the MSI on a network share and assign it via an ActiveDirectory policy to
computers, all with a couple mouse clicks).

Although not very powerful, Visual Studio.NET's built-in Windows Installer
package support appears sufficient for Firefox. I created my own Firefox MSI
without any major MSI-related problems.

Comment 11

13 years ago
*** Bug 246625 has been marked as a duplicate of this bug. ***

Comment 12

13 years ago
Requesting blocking 1.0 as there have been several threads on this recently on
Mozillazine and it does seem like this would help a lot with corporate rollouts.
Comment #10 suggests that this might have an easyish resolution.
Flags: blocking-aviary1.0?
not going to block the release for this, but its something I really want to see
as an option (how is another issue entirely)
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 14

13 years ago
I would suggest that the best way to do this, is produce a STiX XML file in the
installer scripts. This really wouldn't be that bad, but would need reasonable
knowledge of STiX. I have had a quick look at it, and might try and do it at
some stage in the near future.
To clarify: would the existing installer be replaced by an MSI, or would the MSI
be in addition to the existing installer? (If the latter, the summary is a
little misleading.)
(Reporter)

Comment 16

13 years ago
Since Win9x, and probably NT4, don't support .msi natively, I'm not sure if we'd
want to take the replacement approach.  However, those are in the minority, and
we do also provide zip builds.  We could probably get some input from apache.org
on how to do this.
replacement isn't necessary, but this is something that corporate types need/want

based on http://support.microsoft.com/default.aspx?scid=kb;EN-US;292539, the
Windows Installer Engine isn't part of the base install of 95/98/NT, but is for
ME/2k/XP, however it can be downloaded (and a number of people likely already
have it).  For the target audience utilizing MSI, we can safely assume they
already have it.
Summary: Firefox installer for Windows should use the MSI (Microsoft Installer) → Provide Firefox MSI package

Comment 18

13 years ago
it's easy enough to get or make available msi for 9x/nt4. nt3.51 is a different 
story. these days a bunch commercial vendors include the msi engine with their 
product (especially because some os's have the original msi engine and people 
tend to want the first point release).
(Reporter)

Comment 19

13 years ago
Can anyone think of a reason to not use .msi?  NT 3.51?  Zip!

Comment 20

13 years ago
Anyone who has installed a recent version of MS Office (I think Office 2000 and
newer) will already have MSI support on their computer. Even those on Win9x. The
same is probably true for a lot of other MS Apps as well, but I don't have a
list of names. Point is that we can be pretty certain that almost everybody will
have MSI support already. Though of course, until we drop support for Win9x/NT
(which is probably a few years away), we will still need to provide the installer.

In any case, before we start, we need to decide what version of MSI to use.
Windows 2000 comes with 1.1, ME with 1.2, and XP with 2.0. Therefore I think we
have to use MSI version 1.1, so that we can support all Windows 2000
installations without having to upgrade to 2.0. I'm not sure what their
respective featuresets are, but it would certainly complicate things further if
we wanted to use something in the 2.0 featureset. Either we use 1.1 or 2.0.
Using 1.2 doesn't make any sense.

Comment 21

13 years ago
I've seen a model where two (downloadable) installers are offered: one assumes a
correct version of MSI and one that includes the MSI engine as part of the
package.  I imagine software distributed on CD just includes at least the needed
version of MSI and does what needs to be done to get it done.

Comment 22

13 years ago
W2K SP4 (or maybe it was SP3) provides MSI 2.0 on that platform.
(Reporter)

Comment 23

13 years ago
DownloadDownload Windows Installer 2.0 for Windows 2000 and Windows NT 4.0 now

DownloadDownload Windows Installer 2.0 for Windows ME, Windows 98 Second
Edition, Windows 98, and Windows 95 now

http://support.microsoft.com/default.aspx?scid=kb;EN-US;292539

Comment 24

13 years ago
VS.NET can generate installer executables that check and install/upgrade Windows
Installer as necessary. The raw MSI package can be offered for people who know
they have the correct version installed to cut down on the download size.

Comment 25

13 years ago
The problem with including the Windows Installer package within the installer is
that the installer size would jump up from 4.7MB to somewhere in the region of
6-7MB. This is unacceptable as a long-term solution.

Comment 26

13 years ago
I certainly think that the existing installer works perfectly, the MSI version
should be downloadable for network administrators. STiX takes an XML file, and
the stuff you want to package and produces a MSI file. This would fit into how
the installer is currently built well. If we bootstrap it on there the
advantages are pretty easy to see.

Comment 27

13 years ago
I have also built an msi file for Firefox.  We use it at my college.  The 0.9.3
version is available at:

ftp://anon:anon@www.lakeland.cc.il.us/wlilly/Mozilla%20Firefox%200.9.3.msi

I would like to help anyone that developing this and am open to any suggestions
concerning my msi file.  I believe that this is one of the biggest things
keeping corporate people from using Firefox.  Ease of deployment thru Active
Directory is huge when you consider installing to thousands of machines.  Also
file associations and default browser settings can be done during the install
fairly easily if the correct registry settings are known.
(Reporter)

Comment 28

13 years ago
Do you have a shell script that builds the .msi, or did you manually step
through some gui.

Comment 29

13 years ago
Unfortunately I had to step thru some GUI.  I have no idea how to shell script
an msi as the only shell scripting I do is for net administration.  The only
thing that I can provide that comes even close to what you are asking is that I
have a Firefox template that I use when I build the MSI so I don't have to
recreate the GUI portions.
(Reporter)

Comment 30

13 years ago
Well, go ahead and attach what you've got, please.

Comment 31

13 years ago
(In reply to comment #30)
> Well, go ahead and attach what you've got, please.

Can I attach a zip file with the project?  Also it is an InstallShield
Adminstudio project and thus will be useless to most people.  If someone has a
scripting method to create an msi file for this I can provide the dialogs and
such that I use.  This bug is my first posting in bugzilla so I am a newbie to
this.  I am willing to help as much as my limited knowledge can help.  I love
both Firefox and Thunderbird and hope to see some of the corporate features
added that I need to help get support for them where I work.  Collaborative
calendaring and msi support are the big ones for us. Although of course I have
taken care of the msi thing although I will be the first to admit that my skills
with msi's are at best mediocre.
(Reporter)

Comment 32

13 years ago
Yes, you can attach zips.

Comment 33

13 years ago
I cannot attach as it is to big.  A little over 1 MB.  I could put it out on an
ftp server if that will suffice.

Comment 34

13 years ago
(In reply to comment #27)
> I have also built an msi file for Firefox.  We use it at my college.  The 
0.9.3
> version is available at:
> ftp://anon:anon@www.lakeland.cc.il.us/wlilly/Mozilla%20Firefox%200.9.3.msi

I can't express how grateful I am for this. I hope there will be official MSI 
packages of future FireFox versions, it's essential for deployment in large 
organizations such as the school I work at. I'd like to help but I'm not that 
proficient with Windows Installer yet. Please have a look at 
http://www.appdeploy.com/ for more topics related to MSI and application 
deployment.

Comment 35

13 years ago
MSI would really be a dramatic help even for small organizations.  One of the
prime drivers away from Internet Explorer is concern about security issues.  If
Firefox had an MSI installer, an administrator could automatically push browser
patches to every desktop.  Without an MSI installer, this responsibility falls
to the users -- this is a deal-breaker in many cases.

Comment 36

13 years ago
(In reply to comment #9)
> http://sourceforge.net/projects/wix/
> 
> Perhaps WiX would be a good way to do this?  I'm not sure how much its status as
> CPL matters, if any (it looks like the CPL only applies to distribution of code,
> not product use).  It would seem to be a good way to go, as it's been used
> before by Microsoft and has command line tools that would fit into the command
> line based build process the Mozilla tree uses.  (I haven't worked with it,
> tested it, or gone much beyond reading the blurb about it on the WiX site, so I
> might be wrong about its utility for this bug.)

It looks like this may be a decent option indeed.  You create an xml file with
installation instructions.  It seems as if you can even design dialogs...

Some examples are available here:
http://cvs.sourceforge.net/viewcvs.py/wix/wix/doc/examples/

Does the installer do anything besides literally copy files over?  I mean, aside
from showing the license and etc.

-[Unknown]

Comment 37

13 years ago
Ok, created a makemsi script for making an firefox msi with enUS from the zip 
file.  It can be deployed via AD, doesn't require admin to do a first run, and 
installs flash.  it can also set itself up as the default browser (whole 
system).  A few questions, the zip file is vastly different from the .exe/  
There's xpt files, some dll files, .js, etc...., what's going on?  relevant to 
functionality?

I am also having problems using the same procedure to produce localized 
versions.  I tried to make a ja-JP version using the xpi file from the 
Japanese group, and I couldn't get firefox to integrate it.  Directions at 
http://texturizer.net/firefox/localize.html 'How to make a localized Firefox 
build' doesn't work.  Author doesn't respond to email.  
(Reporter)

Comment 38

13 years ago
They're just compiled slightly differently.  The stuff is in there.  We don't
have permission to distribute Flash, so take that out.  Texturizer.net is kinda
old.  Search mozilla.org for localization information.

Comment 39

13 years ago
Thanks for the tips.  Regarding distributing Flash, I believe it is allowed 
for firefox.  I have a license to do so for my software which Macromedia 
sugguested back in April, 2004.  It is called a 'distribution agreement', 
located here 
http://www.macromedia.com/support/shockwave/info/licensing/license.html
It is per product so a new agreement will need to obtained.  

The enabling clause is 2)a)iii)
'through the Internet to end users, solely as a part of or with, with its 
Licensee Product (such as bundled in Licensee¡¦s installer which, in turn, is 
downloaded from the Internet).'

This means the installer needs to incorporate the Flash components which the 
MSI does.  There are some marketing considerations though, like displaying the 
Flash enabled logo, etc. 

Comments welcome.
(Reporter)

Comment 40

13 years ago
What I'm suggesting is that you meet the minimal current requirement: a
scriptable way to create an MSI package.  Bug 229590 deals with whatever plugins
we may bundle.

Comment 41

13 years ago
Eric's port works perfectly on my system. I was able to install and uninstall it
easily and it went smoothly. Much much better than the current system. All my
extensions work fine. Flash works fine, right out of the box.

I recommend this MSI method for 1.0 final.

Comment 42

13 years ago
Tests for my MSI's are being tracked here.

http://forums.mozillazine.org/viewtopic.php?t=138033

Comment 43

13 years ago
Draconpern's msi installer with the Fx 2004-10-01 build also works without flaws
as best I can tell.
(In reply to comment #37)
> Ok, created a makemsi script for making an firefox msi with enUS from the zip 
> file.

Is this script available somewhere for inspection/testing?

Comment 45

13 years ago
(In reply to comment #44)
> (In reply to comment #37)
> > Ok, created a makemsi script for making an firefox msi with enUS from the zip 
> > file.
> 
> Is this script available somewhere for inspection/testing?

http://forums.mozillazine.org/viewtopic.php?p=846746#846746

Comment 46

13 years ago
Here's someone else doing what sounds like a great job. He set and claims to
have achieved the following goals:

1. Deploy FF using Active Directory GPO/Intellimirror
2. Make FF the default browser
3. Set a default profile for new users including correct extensions, shortcuts
and preferences
4. The default profile is set without user intervention or interaction (no
import settings dialog)
5. Add a shortcut to FF on the desktop and Start menu
6. Include necessary plugins (Java and Flash)

http://www.mikrotuki.org/ffguide.pdf
(Reporter)

Comment 47

13 years ago
A deployment guide would be great!  But that's a separate issue. 

Comment 48

13 years ago
yuu

Comment 49

13 years ago
OpenOffice.Org 2.0 (beta) now uses MSI for installing...

Comment 50

13 years ago
I've been able to make my own .msi Firefox install.
The Biggest issue I ran into is that Firefox is *very* specific about the string
it looks for to make sure it's the default browser down to being case sensitive.

This makes it somewhat more difficult (possibly depending on the MSI packager
used) to make Firefox the default browser no matter what directory it is
installed to.

The files used to create my .msi are also available are my site:
http://www.webheat.co.uk/firefox.php

Updated

13 years ago
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Updated

13 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Assignee: bugs → cmp

Comment 51

13 years ago
Mike Dixon,  I wonder if we could plug what you have done into one of the
tinderbox systems and have it kick out an msi package every day?

what do you think it would take to make that happen?

chris h.

Comment 52

13 years ago
I don't think we can make 1.0 on this.  The status still shows as NEW, and 
probably too close to 1.0.
I am releasing .msi's of non-nightly's in the the forum
http://forums.mozillazine.org/viewtopic.php?t=138033

Comment 53

13 years ago
Wouldn't it be ideal if we could sync the msi installer with the regular
installer? Maybe dynamically generate the script that creates the msi from
browser/installer/windows/packages-static. Having a shared set of registry
entries that need to be set might be more of a problem.

Comment 54

13 years ago
(In reply to comment #53)
> Wouldn't it be ideal if we could sync the msi installer with the regular
> installer? Maybe dynamically generate the script that creates the msi from
> browser/installer/windows/packages-static.

Yup, that would be ideal, except currently, all the registry info in the 
mozilla installer are hard coded (AFAIK). Worse, there are options that 
firefox sets which are hard to figure out (eg lots of LXR searches, no Xref 
available). For example, I am working on my msi bug where even if you install 
it with 'set as default browser', it still asks you if you want to set it. 
Grrr.
(Reporter)

Comment 55

13 years ago
(In reply to comment #53)
> Wouldn't it be ideal if we could sync the msi installer with the regular
> installer? Maybe dynamically generate the script that creates the msi from
> browser/installer/windows/packages-static. 
My intention would be that this would eventually replace the current windows
installer.  I think that we'd be able to avoid several of the UI bugs that the
current installer has.

> Having a shared set of registry
> entries that need to be set might be more of a problem.
You lost me there.  


(In reply to comment #54)
> Yup, that would be ideal, except currently, all the registry info in the 
> mozilla installer are hard coded (AFAIK). 
Instead of looking at the installer, try looking at the Options dialog where
that button launches.  Maybe this link will help:
http://lxr.mozilla.org/aviarybranch/search?string=nsIShellService
I found it by searching for the Check Now button.


The current installer does a number of things - including using the xpinstall
engine which will eventually keep track of installed packages and so on, making
it hard to obsolete unless you know all the requirements and features. No one
knows all of this just yet so we can't "replace" anything. 

Comment 57

13 years ago
I don't know much about creating MSI files, but the Office Developer Package and
Deployment wizard doesn't include Windows Installer 2.0.

When installed on a 98 machine (for example) without Windows Installer 2.0 it
pops up a dialog telling the user to download it and directs them to
http://support.microsoft.com/default.aspx?scid=kb;EN-US;292539 (IIRC).

This saves adding Windows Installer to the package.
This is not going to block the 11/9 launch however Chase will continue to work
on it as it is still very important. The msi installer may trickle in before, at
the same time or after the 1.0 release. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Priority: -- → P2
Target Milestone: --- → Firefox1.1

Comment 59

13 years ago
I would like to add that mysql now uses http://sourceforge.net/projects/wix/ to
deploy mysql on windows, so someone might want to look into how they do it and
if they have the scripts/xml files available to the public that can be used as a
reference
(Reporter)

Comment 60

13 years ago
(In reply to comment #56)
> The current installer does a number of things - including using the xpinstall
> engine which will eventually keep track of installed packages and so on, making
> it hard to obsolete unless you know all the requirements and features. No one
> knows all of this just yet so we can't "replace" anything. 

Can you gather a list of requirements and features for this project to meet? 
What needs to be installed so that we can call the xpinstall engine from MSI?

(In reply to comment #59)
> I would like to add that mysql now uses http://sourceforge.net/projects/wix/ to
> deploy mysql on windows, so someone might want to look into how they do it and
> if they have the scripts/xml files available to the public that can be used as a
> reference

wix was first mentioned in comment #9, and I agree that it sounds like a great
way to go.  Documentation in their packages is a .chm file.  The process looks
pretty easy and of course we can dynamically generate the necessary XML files.

Comment 61

13 years ago
for an unoffical MSI packaging for 1.0 see

http://forums.mozillazine.org/viewtopic.php?t=138033

These were built using MakeMSI

Comment 62

13 years ago
mscott also saw this post...

http://forums.mozillazine.org/viewtopic.php?t=166949&sid=09ad647ea29533eaa5aee89a2d0d1319


tuaris
Joined: 02 Jul 2004
	PostPosted: Nov Thu 18th 2004 2:40pm     Thunderbird MSI
I created a MSI package using InstallShield X for use with Active Directory
group policies. I made the project files available at
http://www.danielmorante.com/index.php it's one zip file for Firefox, and
another for Thunderbird. They include all project files needed for building and
editing.

The only problem I'm having is with Advertised shortcuts, I can't get the
installer to "create" certian registry settings and shortcuts on a per-user
basis. If someone could help me out it would be great.

You are free to use this MSI project anyway you wish, jus give me credit and
send back and improvements, changes or fixes.

Updated

13 years ago
Blocks: 271208

Comment 63

13 years ago
Assuming there are no blockers on license issues and it's a better solution, we
should add WiX to the list of candidates for MSI packaging further down the
road.  For now, I'll use whatever information is available in the links listed
in this bug to work on generating a MSI package on our build systems.

Comment 64

13 years ago
Will all the win32 builds be switching to an MSI based installer, or will it be
an alternative download?

Also how feasible is it for an MSI to support a multi-region installer (bug
#269869)?

Comment 65

13 years ago
> 
> Also how feasible is it for an MSI to support a multi-region installer (bug
> #269869)?

you can use ORCA to export the UI strings into a text file, edit those and
import them back in.  The importing part can be scripted (at least with MakeMSI).

Comment 66

13 years ago
Created attachment 166813 [details]
My 1.0-abAB firefox MakeMSI script

This is my current FireFox MakeMSI script.
there's a com interface to msi files which lets you use sql to query / update
the msi tables (via database views).

http://msdn.microsoft.com/library/en-us/msi/setup/installer_object.asp

Updated

13 years ago
Blocks: 271351
Assuming there are no additional complications involved in making an MSI for
Thunderbird, can this bug be morphed to include Thunderbird? It seems daft to
file a new bug if there are no Thunderbird-specific issues.
(In reply to comment #68)
> Assuming there are no additional complications involved in making an MSI for
> Thunderbird, can this bug be morphed to include Thunderbird? It seems daft to
> file a new bug if there are no Thunderbird-specific issues.

There would be Thunderbird-specific issues.  If you need to confirm this, just
look at the contents of mozilla/mail/installer/windows/mail.jst (46K) and
mozilla/browser/installer/windows/browser.jst (26K) -- the contents are entirely
different, and these files are only some of the files that would need to be to
some degree ported to whatever MSI creation method is used, so this really can't
(and shouldn't, if we want to get any sort of traction here) be morphed.
(In reply to comment #69)
> (In reply to comment #68)
> > Assuming there are no additional complications involved in making an MSI for
> > Thunderbird, can this bug be morphed to include Thunderbird? It seems daft to
> > file a new bug if there are no Thunderbird-specific issues.
> 
> There would be Thunderbird-specific issues.
OK then; I've filed bug 274624.

Comment 71

13 years ago
Created attachment 169500 [details] [diff] [review]
Use $(srcdir) for make-msi.pl

When making objdir builds, perl can't find msi/make-msi.pl because it's being
run in the object tree.  Telling it to use $(srcdir) works around this and it
finds the right file.  This patch does not fix the whole bug, of course :D 
Also, since I don't have makemsi, I can't actually test to see if the script
works...  Just that it runs.  $(SRC_DIR) (cygwin paths) did not work for me.
 
(Submitting because a change to .../installer/windows/Makefile.in - rev.1.11 -
made my build die near the end.  Feel free to ignore :D)
Attachment #169500 - Flags: review?(cmp)

Comment 72

13 years ago
Comment on attachment 169500 [details] [diff] [review]
Use $(srcdir) for make-msi.pl

I committed a slightly different form of this patch to CVS just now in
Makefile.in's revision 1.12.  You should not encounter the 'missing
make-msi.pl' error, now.  Can you try another build with the latest trunk to
check that this is the case?
Attachment #169500 - Attachment is obsolete: true

Updated

13 years ago
Attachment #169500 - Flags: review?(cmp) → review-

Updated

13 years ago
Depends on: 229706

Comment 73

13 years ago
I can confirm that this generates a functional MSI with objdir builds now.

Comment 74

13 years ago
The Firefox trunk build machine is now generating an MSI file that installs and
runs the Firefox installer.  Silent installer functionality is not yet available
and is being tracked in bug 229706.

Updated

13 years ago
Flags: blocking-aviary1.1?

Comment 75

13 years ago
Trunk Windows build machines are now generating MSIs based on the installer.  I
have tested these MSIs in a personal deployment and the installation proceeds as
expected with a period of no activity occurring where the installer is invoked
silently.

Can anyone in a position to run a quick test of these MSIs in an automated
roll-out across a small number of machines via Active Directory do so and
provide any feedback?

Comment 76

13 years ago
Please try to design the MSI so that it can be customised (using an MST - a 
transform file). One particular area of customisation, however abhorrent it 
may sound, is that not all corporates will want Firefox to be the default 
browser - they may simply want to be able to install it alongside IE but keep 
IE as the default.

Thanks.

Comment 77

13 years ago
Created attachment 172077 [details]
source to RestoreIExplorer dll to restore explorer association on uninstall

finally cleaned this up. I am uploading my RestoreIExplore.dll source project.
This should be included to restore IE when an uninstall is performed, otherwise
your system is going to be in a very bad state. Instructins in readme.txt.  For
MakeMSI scripts.

Comment 78

13 years ago
Uhm... guys, I am looking at 
http://lxr.mozilla.org/seamonkey/source/browser/installer/windows/msi/firefox.m
m

That's not the way to do an MSI!  You are going to break people's machines.  
The data files really need to sourced by the mm script, not call a setup 
program.  Also, how are uninstalls going to be performed?

Comment 79

13 years ago
Created attachment 172078 [details]
managed firefox.mm

I have changed my earlier script to integrate w/ the firefox build tree.  Can
someone drop this in place and see if it works?  This doesn't set default
browser by default. I also commented out any RestoreIExplore.dll, but if you
want to use that, compile my previous upload.
Attachment #166813 - Attachment is obsolete: true

Comment 80

13 years ago
(In reply to comment #77)
> This should be included to restore IE when an uninstall is performed, otherwise
> your system is going to be in a very bad state.

What if IE wasn't the default browser before Firefox was installed?  Perhaps
backups should be made of existing registry keys before changing them?  Probably
that should be another RFE, but I think it would be very easy at this point to
put that functionality into this MSI file, if not the installer.

Comment 81

13 years ago
(In reply to comment #80)
> What if IE wasn't the default browser before Firefox was installed?

What if Firefox isn't the default browser when the uninstall is performed?  The
default browser should only be changed if Firefox is the default browser at the
time of uninstallation; otherwise it is messing with the settings of other
programs.  See bug 277733.

Comment 82

13 years ago
I would like to see Bug 264889 implemented in this setup, if a new setup is
being created.

Comment 83

12 years ago
Created attachment 175803 [details]
MSI using WiX toolset

Here is my result of playing with the WiX toolset.  It is a wxs file that can
be candled/lighted to create a Firefox 1.0.1 MSI.  Note that it lacks a lot of
features compared to the MakeMSI scripts, but it can be done.  Note that the
source is the 1.0.1 zip install.

Updated

12 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+

Comment 84

12 years ago
(In reply to comment #25)
> The problem with including the Windows Installer package within the installer
> is that the installer size would jump up from 4.7MB to somewhere in the region
> of 6-7MB. This is unacceptable as a long-term solution.

I do not not find this to be "unacceptable" : most downloadable programs out
there have install packages that are about that size (if not a lot more). When
people are downloading a software during its setup process, don't worry, they
show more patience toward its download time than when just waiting for, let's
say, a Web page : they know they are setting up a sensitive application for
their browsing experience, not just "browsing" a Web page... ;-) (and this can
be mentioned if you want to make sure that those dinosaurus, who can't make the
difference between the Web and their hard drive, really understand what they are
doing - but I think that most people are aware of this nowadays)

On the opposite, if I've noticed that this app's installer would weight less
than 2-4 megs, I would've thought "oh, another school project... let's pass",
especially for such an app, that's supposed to include many good features to be
contemporary and competitive. You know, it's about the same psyche as for many
consumers, to whom their expenses are a sign of their whealth (and thus their
vanity : being rich is considered a human value for many) : the price in itself
sets some quality standard in many people's mind, even without actually having
tried the product. We can make the same parallel between the weight of an
install package and its underlying quality (which is stupid of course, you and I
know it as we are "knowledgeable" of the tech arena, but that's not the case for
the majority of people though).
Blocks: 267888
No longer blocks: 271351

Comment 85

12 years ago
OpennOffice.org's version 2 beta uses a pretty well-designed MSI. Maybe they
could be helpful to Mozilla?

Updated

12 years ago
Blocks: 163993

Updated

12 years ago
No longer blocks: 163993
(Reporter)

Comment 86

12 years ago
This will need to mix well with the Deer Park update mechanism.  Is this still
going to make 1.5?  Do we need a separate bug for MSI & Updates?
(Reporter)

Comment 87

12 years ago
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

There is no MSI for 1.6a1

Also, the MSI package didn't prompt me to install developer tools when I chose
custom.

Updated

12 years ago
QA Contact: bugzilla → installer
pushing onto the nominations list, but I think we're at a point where we aren't
going to see a proper MSI for 1.5
Flags: blocking-aviary1.5+ → blocking1.8b4?

Updated

12 years ago
Flags: blocking1.8b4? → blocking1.8b4-

Updated

12 years ago
Flags: blocking-aviary2.0?

Comment 89

12 years ago
(In reply to comment #88)
> pushing onto the nominations list, but I think we're at a point where we aren't
> going to see a proper MSI for 1.5

Or of any of version at all... I am not in favor of MS formats, even though it's
Windows one is talking about, but truth be told, this would be amazingly helpful
for lots of system admins in offices and such, and I think it should be a priority.

Did anyone try to contact apache win32 devs or the OOo team regarding this?

Comment 90

12 years ago
*** Bug 314655 has been marked as a duplicate of this bug. ***

Comment 91

12 years ago
As a System Administrator, I have gotten many small shops to standardize on Firefox as the default browsers (justification in TCO due to spyware/virus/foistware in pre-WinXP-SP2 operating system).

I would like to automate installations upon log-on for ALL dekstops through
Group Policy Object facility within Active Directory environment, but I cannot
do this with Firefox, as it is packaged as an .EXE file. Unfortunately in order
to harness this level of automation, the software must be packaged as an .MSI
file.  I have been successful with deployments of Perl through ActiveState's adoption of MSI.

Non-Automation of installs/deployment (example: anti-virus) is definately a blocker for selection of technologies at large corporations.  I know of corporations like Citicorp that don't use IE for security purposes.
This is something I think we want/need sooner instead of later, but we'll need one of our build gurus, and I don't think Chase has cycles to do this type of thing at present.

Benjamin? Other volunteers?
Assignee: chase → nobody
Flags: blocking-aviary2? → blocking-aviary2+
Keywords: helpwanted

Comment 93

12 years ago
I'd like to volunteer, contingent on timeframe.  I re-wrote the MSI installer for TortoiseSVN (http://tortoisesvn.tigris.org) using the WiX toolset (http://wix.sf.net).  I would describe my WiX ability as competent but not advanced.

I would not be able to produce graphics of the quality you guys seem to do as a matter of course, but I would be able to provide detailed requirements for such.

I would prefer to work to a spec detailing what the current installer does, instead of attempt to replicate what it does based on what I as a user can see it doing - I might miss stuff.  I would also prefer to start simple and work up from there.

What's the deal - do I just jump in, provide WiX code (I see someone already has, but without a UI), and instructions on how to integrate it into the build?  I don't know whether the WiX tools work on non-Windows platforms (they require .NET; don't know if they work with Mono), and I also don't know much about your build process; guidance there would be appreciated (links to building on Windows probably sufficient).

Comment 94

12 years ago
(In reply to comment #93)

Oh; 'scuse me.  It does have a UI.  WiX has moved on since February a bit, though, and now provides a UI common library and things.
I don't think there's a formalized spec, but there's probably room for improvement in our current installer.  Graphics we can handle quite easily so its mostly a matter of making it build within the tree and implementing whatever spec we hook up.

ccing beltzner, since I think he had something like a spec around at some point.
What I would like to see is the MSI use the ZIP build as a starting point, not the installer: it can just extract the files to the system as appropriate. Then we need to recreate the logic to register the app in the Windows registry and create appropriate shortcuts, matching up with the existing code at

http://lxr.mozilla.org/mozilla/source/browser/installer/windows/browser.jst#115
and
http://lxr.mozilla.org/mozilla/source/browser/installer/windows/ab-CD.jst#10

Comment 97

12 years ago
(In reply to comment #83)
> Created an attachment (id=175803) [edit]
> MSI using WiX toolset
> 
> Here is my result of playing with the WiX toolset.  It is a wxs file that can
> be candled/lighted to create a Firefox 1.0.1 MSI.  Note that it lacks a lot of
> features compared to the MakeMSI scripts, but it can be done.  Note that the
> source is the 1.0.1 zip install.

Would the frontmotion msi file solve all of these issues? 

http://www.frontmotion.com/Firefox/fmfirefox.htm

Has anyone talked to the front motion people about the msi file. an msi file for firefox would eliminate the biggest roadblock to widespread corporate adoption of firefox...
(In reply to comment #97)
> 
> Has anyone talked to the front motion people about the msi file. an msi file
> for firefox would eliminate the biggest roadblock to widespread corporate
> adoption of firefox...

Frontmotion has also been mentioned as a possible solution to bug #267888 (Windows 2000/XP/2003 Group Policies support).  The lack of GP support is also a corporate issue.

Comment 99

12 years ago
The problem with Frontmotion Firefox is that the icon is changed, and the word "Mozilla" is replaced with the word "Frontmotion".  Both of these changes devalue the Mozilla group and brand.  Also, their page says that they may start charging for MSI's at some point in the future.  We should not rely on this company to meet our current and future needs.

Comment 100

12 years ago
> The problem with Frontmotion Firefox is that the icon is changed, and the word
> "Mozilla" is replaced with the word "Frontmotion".

You *do* realize that because Frontmotion is distributing a modified version of Firefox (called their "Community Edition", with GP support among other things), they are forced by mozilla's licensing/trademarks to change the name.

Comment 101

12 years ago
I understand what you are saying, but deploying a program called "Frontmotion" to thousands of computers on a corporate network, when most people are only just starting to learn the word "Mozilla" is not a good idea on the network I administer.  On the same note, people look for icons & colors, occasionally more than the name below the icon, so if we start distributing a different kind of icon here from what people are starting to become accustomed to, then Firefox will have fewer converts, at least at my location.

My main concern is that relying on a company to re-package an open source program into a form we can all use kinda goes against the spirit of the whole project.

Comment 102

12 years ago
I don't think it does. They do it for free, and have said that if they will charge, it will only be for the purpose of covering development costs. I wish they'd release any source used, but I'm not going to throw out the baby with the bathwater. Besides, at issue isn't getting them to do it, I didn't think, but asking them how they do it and adding that as a script to the make file a la '$ make msi'. Given that they've expressed that it is tedious to do it, they may be amenable to it. If not, then they truly aren't holding to the spirit of things, and I see no reason to continue to concern ourselves with it, but only continue the effort here.
> My main concern is that relying on a company to re-package an open source
> program into a form we can all use kinda goes against the spirit of the whole
> project.

Not to add too much noise to this discussion, but that's basically the whole point of the Mozilla Corporation, so I don't think that model is inherently flawed for us.

Comment 104

12 years ago
(In reply to comment #103)

Relying on Frontmotion is an absolute no-go.  I'll be clear and say I think what they've done is really great, I have exchanged many emails with Eric from Frontmotion and, indeed, one of the ADM templates that Frontmotion's MSI uses was written by myself.

However, there is a fundamental flaw for those who have used the Frontmotion MSI, namely - they are doing it for free, as a favour to the community and have no service commitment to this.  What I mean by that is, what if a very critical, 0-day flaw comes out and the recommended resolution is to upgrade to the latest version of Firefox.  This third-party MSI might be produced in hours, but the guys from Frontmotion may be busy, may be away on holiday and it could take weeks.

What I am saying is that producing an MSI is not just a technology issue, but is a service commitment.  There is no point unless there are set Service levels which say something along the lines of "an MSI will be produced for any patch within 24 hours".

That's not an unsurmountable task.  For any new version of Firefox, I produce an MSI for Firefox within a couple of hours.  Unfortunately, that is using Wise Package Studio and my license says I cannot redistribute the MSI outwith my organisation.  However, I could put significant input into the manifest of what should be in there, validate the ICEs, QA, etc.  I have also created an extension (ADM XPI) which could be used to allow any setting to be set via GPO.

However, I believe that it is best to concentrate on trying to produce a script for WiX or MakeMSI, some documentation on how to convert that into an MSI, and most of all, a commitment from Mozilla Corporation to eventually take up that service commitment for any updates for Firefox.

Comment 105

12 years ago
What can be learned from the Thunderbird folks who are already building MSIs?

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-1.6a1.en-US.win32.installer.msi

See also Bug 274624 and Bug 229706

Comment 106

12 years ago
It could be useful to see the MakeMSI file they use to build that.  However, it is far from being anything that could be described as a useful MSI.  Looking at the MSI, it is simply the same as the MSIs that came out of Firefox early on last year - it simply wraps the setup files and then calls the setup.exe in command-line quiet mode.

This will lead to it installing correctly, but being virtually unconfigurable and will also fail in the other key areas of MSI such as self-repair and uninstall.

Comment 107

12 years ago
It would be a start though - for those of us desperate for anything. If anything, it could serve as a catalyst for someone to take the reins and add the extra MSI functionality.

Comment 108

12 years ago
(In reply to comment #107)
> It would be a start though - for those of us desperate for anything. If
> anything, it could serve as a catalyst for someone to take the reins and add
> the extra MSI functionality.

Hmm... Or it could make it so that people say 'we have an MSI that works, why bother?'

Also, for corporate installations, this sort of installer could cause more problems than it solves. If people try it and it doesn't work or uninstall properly, it could turn them off FireFox for good. How are you going to explain to them that 'we've fixed the MSI installer so it works properly now' - they'll ask why we didn't get it right the first time.

I really think this should be done properly from the word go.
(Reporter)

Comment 109

12 years ago
No mention of MSI on http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-02-07#Installer
Some of the makemsi files where removed from the CVS repository for licensing issues - see bug 324118.
Do we have any idea why the MSI files are so big?

Does Microsoft not do any compression at all for the MSI files?

Comment 112

11 years ago
The MSI itself just has the files as they come, AIUI, and you are advised to use cabinet files to compress the data. As far as I can see, the best way is to take all your files, make a single .cab file of them, and then tell the MSI that each file is inside that .cab file. In particular, the item "Including a Cabinet File in an Installation" on the following page seems to do well at explaining how it is done:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/using_cabinets_and_compressed_sources.asp

Comment 113

11 years ago
> Do we have any idea why the MSI files are so big?

What makes you say that?  IMO, the overhead of .msi files is small compared to the payload we're talking about here.

> Does Microsoft not do any compression at all for the MSI files?

Compression is optional.
(In reply to comment #113)
> > Do we have any idea why the MSI files are so big?
> 
> What makes you say that?  IMO, the overhead of .msi files is small compared to
> the payload we're talking about here.

On my initial tests, the MSI was 6 meg - that's 20% bigger - I'd love to get the MSI files to a size that Mozilla would use them as the default install package instead of going to Nullsoft - that would require them being under 5 MB.

Comment 115

11 years ago
The .msi's format simply provides more features (ease of customization/deployment/upgrades, automatic repair among a few), so one would expect it to be at least a little larger.  And, frankly, I (and most AD admins I'd wager) could care less whether the .msi version is a little (20%) bigger.

Comment 116

11 years ago
MSI files support MS .cab compression either within or external to the MSI itself. The overhead of the MSI schema itself is relatively small -- certainly under 200kB. If greater compression is desired, it's easy to wrap the MSI and a call to msiexec in a self-extracting executable using whatever compression you like. (Note: This is what Adobe does with Acrobat.)

Call this the hair that broke the camel's back... or something. Whatever.

Most (if not all) AD installations of Firefox via MSI will be through an administrative installation point, which will take up the full 15-16MB of an uncompressed installation. The difference between 5 and 6MB is irrelevant. Mozilla has refused to provide (or accept any number of offers to create) an MSI-based installer -- even as an option alongside other installation mechanisms. Firefox chooses file versioning rules that specifically break Windows Installer's healing and update capabilities. Firefox insists on using the uninstall program for functionality unrelated to uninstallation (making it impossible to eliminate the otherwise unnecessary uninstall program from an MSI if one were made). Firefox still refuses to provide a mechanism of patching Firefox installations for non-admin users that doesn't require un/re-installing or touching every affected box (vastly unrealistic given the frequency of security updates). Firefox provides no means of pushing out administrator-defined "mandatory" and "recommended default" settings. Firefox does not use the registry, so per-setting access control is impossible. (I realize this is done in the interests of interoperability.) Firefox does not uninstall cleanly. Firefox has not fixed cifs file-handling bugs that primarily affect roaming profiles in enterprise environments. Documentation about Firefox, preferences, customizability, etc. is sketchy, aside from source code. The sum of these observations can be interpreted as hostility to deployment of Firefox in enterprise environments. 

In light of this, why should an enterprise struggle to deploy Firefox and take on the huge cost of deploying continuous updates when (from an enterprise deployment perspective) vastly superior products are available? You'll want examples... Opera does better in some ways, and of course IE has the deployment and update stuff nailed.

(Oh, and don't bother answering that question, because I already know.)
(In reply to comment #116)
> Mozilla has refused to provide (or accept any number of offers to create) an
> MSI-based installer -- even as an option alongside other installation
> mechanisms.

That is the problem I am trying to solve.
> Firefox chooses file versioning rules that specifically break
> Windows Installer's healing and update capabilities.

Can you provide more information on this please?

> Firefox insists on using
> the uninstall program for functionality unrelated to uninstallation (making it
> impossible to eliminate the otherwise unnecessary uninstall program from an MSI
> if one were made).

Can you provide more information on this please?

 Firefox still refuses to provide a mechanism of patching
> Firefox installations for non-admin users that doesn't require un/re-installing
> or touching every affected box (vastly unrealistic given the frequency of
> security updates).

Isn't this solved with the new update feature?

> Firefox provides no means of pushing out
> administrator-defined "mandatory" and "recommended default" settings.

Actrually, the CCK does this (http://www.mozilla.org/projects/cck)

> Firefox
> does not use the registry, so per-setting access control is impossible. (I
> realize this is done in the interests of interoperability.)

Do you mean use the registry instead of prefs.js for user configuration?

> Firefox does not
> uninstall cleanly.

Can you be more specific on this?

> Firefox has not fixed cifs file-handling bugs that primarily
> affect roaming profiles in enterprise environments. Documentation about
> Firefox, preferences, customizability, etc. is sketchy, aside from source code.
> The sum of these observations can be interpreted as hostility to deployment of
> Firefox in enterprise environments. 

Again, a problem we are trying to help solve.

> 
> In light of this, why should an enterprise struggle to deploy Firefox and take
> on the huge cost of deploying continuous updates when (from an enterprise
> deployment perspective) vastly superior products are available? You'll want
> examples... Opera does better in some ways, and of course IE has the deployment
> and update stuff nailed.
> 
> (Oh, and don't bother answering that question, because I already know.)
> 

(In reply to comment #117)
> (In reply to comment #116)
>  Firefox still refuses to provide a mechanism of patching
> > Firefox installations for non-admin users that doesn't require un/re-installing
> > or touching every affected box (vastly unrealistic given the frequency of
> > security updates).
> 
> Isn't this solved with the new update feature?

Only if the Firefox install directory has write access for the user.
I don't think you can characterize "indifference" as "hostility" but otherwise there's some valid points there.  We're heavily focused on the consumer space, but that doesn't mean we're going to be hostile to efforts to spread the love.

That said, I don't see the real value in shipping a stock Firefox MSI right now.  What I _do_ see the value in is in building out a customization kit that would allow the creation of Firefox MSI packages for internal deployments, since its the custom packaging that really helps solve the problems (i.e. setting up remote pref locking, custom bookmarks/homepage, etc).  Obviously there are some significant redistribution licensing issues involved there, but that's the path that I think we'd ultimately benefit from the most.
Can we move this meta-discussion to a wiki page somewhere and identify a realistic set of requirements for a MSI? We're not "refusing" MSIs in general, but we're going to need somebody to contribute a reliable MSI build system which when installed matches the binary bits produced by the .exe installer.

A lot of the requirements articulated around honoring preferences and group policies from the registry is not really related to the MSI itself at all, except to the extent that apps shipped as MSIs also typically honor registry-set prefs and group policy.

Let's keep this bug about the MSI packaging and installation implementation and use other existing bugs to discuss prefloading and group policy.

Comment 121

11 years ago
I concur with Benjamin Smedberg.  I actually want to address the later issue in a seperate bug where I can look deeply into the issue and provide plausible solutions, but I haven't put together something until this one issue is resolve: MSI package.  Let's just have one battle at a time.

I've just started a contract with EDS and Department of Defense (USA), and I don't know what my influence will be for using Firefox due to security issues with some bundled product in Windows, but I hope I'll have the same success as I have had with previous clients in SF financial district.  Given the number of installs would be in the thousands and thousands (assuming I capture some attention on the topic) this well, is bug quite interesting.

I'm totally ignorant as far as implmentation of MSI (install and uninstall), but I would be willing to sacrifice my gaming time and personal project time on this, welcome e-mails or mailing list, forum, etc. on this...
this isn't really on radar, and not a blocker for Firefox 2.
Flags: blocking-firefox2+ → blocking-firefox2-
Priority: P2 → --
Target Milestone: Firefox1.5 → Future

Comment 123

11 years ago
(In reply to comment #122)
> this isn't really on radar, and not a blocker for Firefox 2.

I still don't understand why not.

When Firefox came out it got incredible positive feedback from the press. Almost all of the articles identified the biggest flaw in Firefox - the lack of features for corporations. Without the features, Firefox doesn't have a chance at unlocking IE's corporate stranglehold. 

Business don't want to muck with creating MSIs or relying on unsupported 3rd party tools. What happens when Firefox tries to update itself automatically after it was installed from an MSI? How will administrators deploy updates? Why would they be expected to put in lots of extra time when they already have a working browser (IE). IT personell need to justify their time to their boss - how are they going to justify an expensive (and in management's eyes, risky) company-wide Firefox deployment?

MSI is Windows' native installation package. Saying you don't want to support it directly is about the same as telling users that you don't fully support Windows. 

No offense, but the entire reason Firefox is popular on the Windows platform compared to other non-Microsoft browsers is the fact Windows is treated as a "first class citizen" - it was designed to look and feel like a true Windows app. No posix dependancies/libraries to install, X-Windows GUI widgets, etc.

Every time I hear of a new Firefox release, I check to see if the following things have been resolved:
* Does it support policy deployment?
* Is it MSI?
* Have they gotten rid of that horrible bookmark.htm file?

The only impression I've gotten from the discussion of this bug/feature request is the typical "It's an Evil Microsoft feature who cares about that" response I'd expect from other Open Source projects, but not Firefox. 

122 comments later, and your Windows users, politely begging for this critical feature, have been swept under the carpet.

Comment 124

11 years ago
Re: shadowchaser@transfur.com 

Hear, hear!  [clap clap clap]

Comment 125

11 years ago
I have been doing my own MSI for sometimes now, so I can give you my thoughts.

From the my users perspective, their risk is that I may not be around forever creating the MSI.  Of course I will do my best and have been for a while which is why I have such a large install base now.

The MSI's do disable the auto update feature.  This is required as they won't have write permission to the installed files.  My community edition does support group policy w/o ugly and unsecure login scripting.  But in order to support that feature, I did have to add Windows specific code.  I don't think the dev team wants to take the development in that direction.  As for bookmark.htm, you got me there. :/

(In reply to comment #123)
> working browser (IE). IT personell need to justify their time to their boss -
> how are they going to justify an expensive (and in management's eyes, risky)
> company-wide Firefox deployment?
[snip]
> Every time I hear of a new Firefox release, I check to see if the following
> things have been resolved:
> * Does it support policy deployment?
> * Is it MSI?
> * Have they gotten rid of that horrible bookmark.htm file?
We have consistently stated that our goal is to support consumers, enterprise deployment is an entirely different scenario that we're not set up to support at present.  Entering the enterprise market requires a lot more than just an MSI and some group policy support, its a matter of adopting an entirely different focus than targeting the consumer market.  Right now, it doesn't make a lot of sense for us to do that.

Comment 127

11 years ago
(In reply to comment #126)
> We have consistently stated that our goal is to support consumers, enterprise
> deployment is an entirely different scenario that we're not set up to support
> at present.  Entering the enterprise market requires a lot more than just an
> MSI and some group policy support, its a matter of adopting an entirely
> different focus than targeting the consumer market.  Right now, it doesn't make
> a lot of sense for us to do that.

Actually the enterprise market has been consistently stated as an important growth area.

"Continuing to fill needs for enterprise customers, seeing wide deployment in Fortune 500 companies, universities, as well as wherever high quality and reliability are important." Chris Hofmann, http://www.digital-web.com/articles/chris_hofmann/

"A: It fills a wide variety of needs in many different niches. We have talked to several enterprise and large organizations that have Mozilla deployments in place, or are considering them." Chris Hofmann, http://www.freeos.com/articles/4695/

I disagree with you that entering the enterprise market will take a lot more than an MSI and GP support. In most cases this is the only reason Firefox has not been deployed in this environment. 

This is a "Perfect Solution" fallacy. "The perfect solution fallacy is a logical fallacy that occurs when an argument assumes that a perfect solution exists and/or that a solution should be rejected because some part of the problem would still exist after it was implemented." http://en.wikipedia.org/wiki/Perfect_solution_fallacy

For example, we shouldn't put seat belts in cars because people will still die in traffic accidents.
(Reporter)

Comment 128

11 years ago
They're not saying they won't make an MSI.  They're saying they won't have it in time for Firefox 2.0.  As always, your assistance in creating patches is appreciated.  

Comment 129

11 years ago
It's not clear why enterprise support is such a low priority.  What people use at work is fairly likely to trickle down to what they use at home, whereas the converse is not true.  Firefox had a golden opportunity to capture market share when the press was obsessed with IE's vulnerabilities.  But as everyone here has pointed out, without an MSI it just did not make sense to deploy.  That's the major feature IT managers want.  The other enterprise stuff is just gravy.

I worry that you're going to look back at this as a huge strategic blunder.


(In reply to comment #126)
> We have consistently stated that our goal is to support consumers, enterprise
> deployment is an entirely different scenario that we're not set up to support
> at present.  Entering the enterprise market requires a lot more than just an
> MSI and some group policy support, its a matter of adopting an entirely
> different focus than targeting the consumer market.  Right now, it doesn't make
> a lot of sense for us to do that.

People routinely use the same software at home as they are accustomed to using at work or have even been taught to use at work (sometimes at considerable expense).  Corporate usage would also be a huge acceptance for Firefox, so I don't understand why these features are viewed as being so insignificant.

I don't really understand either why MSI wasn't used in the first place.  It is The Proper Way to install software on Windows platforms and has been for a considerable time.  I can actually live without GP, but MSI and corporate updates are a must.

So when is MSI and GP going to be a blocker?  In version 3.0 or 4.0 or ...?  Is MSI and GP going arrive to Firefox long after Windows Vista and IE7 (with its new look, tabs, improved printing, RSS feeds, integrate search, improved security; http://www.microsoft.com/windows/ie/ie7/about/features/) and all corporate support?

Please remember that Microsoft won the (1st) browser war and killed Netscape.  It can win another browser war and kill Firefox, and as far as Microsoft is concerned, the war probably hasn't even started yet.  Firefox vs. IE7 might become an epic battle and corporate support is needed.

Comment 131

11 years ago
I don't see why a msi with the basics it can't be, it was part of the early 1.1  (became 1.5) specs, and in the early part of it there were daily builds with msi installs. I think they were stopped due to license issues with the particular tools used to build it but I think Mozilla has since moved to a different installer system (NSIS??) since so a basic msi should be available at almost zero effort, and while it doesn't necessarily prove all the 'bolt down setings with AD+GPO' that would be very sweet in the corporate world for most small to medium organisations to be able to do forced automated msi upgrades to ensure security and consistency across the organisation with minimal administration effort would be a good start and often more than enough (which is the case in my organisation as we aren't overly interested in bolting down the application but would like to force upgrades with minimal admin effort to enforce security).
(In reply to comment #129)
> It's not clear why enterprise support is such a low priority.  What people use
> at work is fairly likely to trickle down to what they use at home, whereas the
> converse is not true.  Firefox had a golden opportunity to capture market 

Evidence shows the contrary, actually. People enjoy choice, and what we've seen is IT departments who convince their parent corporations to deploy Firefox based on requests from users who've switched at home. That enterprise innovation leads home use is a fallacy. Countless examples show that consumer/home technology leads enterprise (ex: IM, blogs, search, wiki, etc).

> when the press was obsessed with IE's vulnerabilities.  But as everyone here
> has pointed out, without an MSI it just did not make sense to deploy.  That's
> the major feature IT managers want.  The other enterprise stuff is just gravy.

Agreed. The problem is that they don't just want MSI. In fact, most IT shops that require MSI also require the sort of functionality that's provided by the CCK: group policies, ability to pre-populate profiles, restricted IP ranges, special proxies for internet use tracking, etc, etc.

This bug hasn't been WONTFIX'd because, well, we think it's worth fixing. That said, the value isn't worth blocking a release, nor has it gotten to be a high point on anyone's radar. Perhaps the IBMers working on CCK would like to take it or something like it. Perhaps you would like to start building a list of the features that IT departments would truly require, prioritizing the buglist, and driving the development of the feature.

Own it, baby, own it. :)

> I worry that you're going to look back at this as a huge strategic blunder.

It would rank somewhere in the middle of the list, don't you worry!

Comment 133

11 years ago
Personally in terms of priority in the enterprise feature list, the MSI tops the list.

Without Frontmotion's MSI package Firefox would not be deployed on our University desktops. The minute Frontmotion drops the MSI support, or starts charging for it, is the same time when an automated removal of the Firefox from all desktops takes place.

The rest of the features like GP and profile specific user configuration things are less important when the browser can't be installed to begin with.

The browser cannot be installed as there isn't enough manpower to visit each machine to do a manual install, and visit each machine when an update comes out.

I guess the ability to do an install of Firefox will be possible as soon as Microsoft finishes the aquisition of Softricity, so at least there is light at the end of the tunnel. I expect Microsoft will announce pricing on the new rebranded product in about 1 year, with a release of the software soon afterwards.

Comment 134

11 years ago
(In reply to comment #132)

> Agreed. The problem is that they don't just want MSI. In fact, most IT shops
> that require MSI also require the sort of functionality that's provided by the
> CCK: group policies, ability to pre-populate profiles, restricted IP ranges,
> special proxies for internet use tracking, etc, etc.
>
> This bug hasn't been WONTFIX'd because, well, we think it's worth fixing. That
> said, the value isn't worth blocking a release, nor has it gotten to be a high
> point on anyone's radar. Perhaps the IBMers working on CCK would like to take
> it or something like it. Perhaps you would like to start building a list of 
> the features that IT departments would truly require, prioritizing the 
> buglist, and driving the development of the feature.
>
> Own it, baby, own it. :)

I agree with you there. As much as I would like to see it in Firefox 2.0, until there is an established plan for MSI support it wouldn't make sense to block an entire release at this stage for a feature that hasn't even entered initial development.

However, if this project gets off the ground in time - who knows? 

* What technology will be used to build the MSI, and how will it be integrated into Firefox's build process? Would the open source WiX project be suitable? How do we get the build process ready for MSI development, and ensure it doesn't block any releases? How do we get the MSI project off the ground in relation to the overall build?

* The software update portion of Firefox will likely need modifications to support patches to MSI modules. Do we redeploy 

* Is having a depdencency on the Windows Installer API acceptable for all Windows Firefox releases? How will down-level clients be handled? I imagine using an older release (v1 or v2) of MSI would mean a larger number of clients would have it installed, but what happens in the event they don't have the required Windodws components? Package the MSI redistributable with Firefox? One option would be to ship with some sort of binary bootstrapper that would handle the redistributable detection/install/update before the MSI itself is launched and download it on demand. Another option would be to have to Windows distributions - one of legacy (95,98,etc) and one for the newer OSes that ship with recent versions of Windows Installer.

* Windows Vista will include new technology for Windows Installer. One of the biggest changes is that it is possible to patch software without being logged in as administrator, provided that the authenticode certificate on the patch matches the one on the original MSI package. Windows Vista will ship with LUA (limited user accounts) by default - switching to MSI now will give Firefox a huge advantage when it comes to automated patching later. The nightmare scenario will be when Vista comes out and the existing Firefox updater is unable to modify files in the Program Files directory. Firefox's credibility will be damaged - many computers will not be automatically patched when vulnerabilities occur. Technically this is a problem right now, but most home users run with accounts that have administrator rights.

* Any policy/GPO related tasks should be done afterwards - there's no point implementing them before the MSI itself, or blocking the MSI due to lack of group policy support. One solution for group policy would be to have a standard "Firefox" key in the policy section of the registry, with a named value matching the name of a Firefox configuration option. Want to have a policy to change the homepage? Create a key called "browser.startup.homepage", matching the existing Firefox preference name. An ADM template could be developed, similar to the IE one, that include the typical settings an administrator would want to set.

Any additional policy support (ie/ the IP range blocking that was mentioned) would be done by adding new Firefox preferences. The GPO support in Firefox would consist of a module to load preferences or enforced policies from the registry and being able to "lock" preferences from being changed. 

I don't know enough about Firefox development to "own" this - but how do we get started? Get buyin from the people in charge of the build process and automatic update module? 

Comment 135

11 years ago
(In reply to comment #134)

> * What technology will be used to build the MSI, and how will it be integrated
> into Firefox's build process? Would the open source WiX project be suitable?
> How do we get the build process ready for MSI development, and ensure it
> doesn't block any releases? How do we get the MSI project off the ground in
> relation to the overall build?

WiX is the way I would suggest to go.  I have been looking at it and would like to work towards a WiX script which other IT admins can then take to compile their own installs.  Until Mozilla release an MSI themselves, this is as far as I think anyone should take it.

> * The software update portion of Firefox will likely need modifications to
> support patches to MSI modules. Do we redeploy

Minor issue.  Firefox is small enough to remove and reinstall without affecting users too much

> * Is having a depdencency on the Windows Installer API acceptable for all
> Windows Firefox releases? How will down-level clients be handled? I imagine
> using an older release (v1 or v2) of MSI would mean a larger number of
> clients would have it installed...

A non-issue.  Microsoft Installer databases tend to be backwards compatible.  Newer MSIs simply feature more tables which it gets information from.  If the MSI engine on a machine is, say, Version 2, it simply doesn't support functionality introduced in Versions 3, 3.1 and forthcoming in 4 (such as the patching technology you mentioned).

It would make sense to include the MSI engine redist until support for Firefox for Windows 98 and the like still exist.  However, if they are talking about dropping support for those older versions of Windows, this isn't necessary.

> * Any policy/GPO related tasks should be done afterwards - there's no point
> implementing them before the MSI itself, or blocking the MSI due to lack of
> group policy support. One solution for group policy would be to have a standard
> "Firefox" key in the policy section of the registry, with a named value
> matching the name of a Firefox configuration option. Want to have a policy to
> change the homepage? Create a key called "browser.startup.homepage", matching
> the existing Firefox preference name. An ADM template could be developed,
> similar to the IE one, that include the typical settings an administrator would
> want to set.

This already exists, almost exactly as you describe it, as a proof of concept extension I wrote.  Can be found here:  http://homepages.ed.ac.uk/mcs/GPOforFirefox.zip

Any value set at HKLM\Policies\ADM\Firefox will be set as default and changeable, any at HKLM\Policies\ADM\Firefox\Locked, will be set and locked, and values can be set in HKCU at the same place.  This is a very small, easy to implement bit of code I will look to implementing as a patch to Firefox.  Since Firefox 1.5 added in the windows-registry-key interface, you can enumerate the Firefox registry key in the Policies area and then convert them easily to pref and lockpref.

However, saying all this, I kind of agree with what Mike Conner said.  There has to be some fundamental changes to the way Mozilla Corp do things before Firefox can be completely suitable for the enterprise.  A simple example is End of Life for major versions of Firefox need to be sensible and projected much further in the future.  When you consider many educational establishments are only able to update major versions of their apps once a year (eg.  during summer, when lecturers are updating course material for the coming academic year), they would need every major version (such as Firefox 1.0.x) to be supported and patched for 2 years minimum (up to a year until deploy + a year in operation).  There are also some other, less palatable, areas such as Mozilla giving some voice in future direction to those who deploy Firefox on a major scale.  For example, it would be a big risk if a major international bank was to base a mission-critical application on Firefox only to find the functionality its based upon is removed or changed in a new version.

Finally, I do believe Mozilla needs to take a lead on policy here.  There are some dangerous precedents being set.  Whilst Frontmotion have proven themselves to be trustworthy, a reliance on third-party MSIs is dangerous.  It really leaves the door open for another third party to produce an MSI based on the fact that third party MSIs are OK, and then slip in some malicious software (and trust me, the irony that I am saying this whilst pointing to an extension hosted somewhere other than Mozilla's site is not lost on me!).
> Another option would be to have to Windows
> distributions - one of legacy (95,98,etc) and one for the newer OSes that ship
> with recent versions of Windows Installer.

FWIW, that becomes less of an issue on trunk, where Win9x won't be supported anyway.

Comment 137

11 years ago
Should this be blocked by:

Bugzilla Bug 289370
Firefox updates should only show up in Add/Remove programs if Show Updates is checked
(In reply to comment #135)
> However, saying all this, I kind of agree with what Mike Conner said.  There
> has to be some fundamental changes to the way Mozilla Corp do things before
> Firefox can be completely suitable for the enterprise.  A simple example is End
> of Life for major versions of Firefox need to be sensible and projected much
> further in the future.  When you consider many educational establishments are

So now we're getting into why MoCo says that they don't want to sign up for "enterprise support". The strain on QA and Release resources is already near the breaking point, and extending our lifecycle on apps will just make that worse. Classically, enterprise vendors make their money on lifecycle support, selling that support for dollars. MoCo doesn't do that, and the free-software model doesn't scale when you have customers saying "well, but we want you to support it on a lifecycle basis that fits our corporate policies/IT refresh structures."

This is kind of where I was going in my previous comment: is producing an MSI useful when the project itself can't make the sort of promises that enterprise consumers might require? Is it just the MSI that's required, or are there other strings? What are the full costs, and the full expected return?

> Finally, I do believe Mozilla needs to take a lead on policy here.  There are
> some dangerous precedents being set.  Whilst Frontmotion have proven 

Mozilla needs to weight the potential benefits against the potential losses and figure out what's best for the future survival of the project. So far, every time that analysis has been made, the costs have been too high.

Comment 139

11 years ago
(In reply to comment #138)
> This is kind of where I was going in my previous comment: is producing an MSI
> useful when the project itself can't make the sort of promises that enterprise
> consumers might require? Is it just the MSI that's required, or are there other
> strings?

Yes, an MSI is useful on it's own. We currently deploy Firefox in this manner with no additional modifications, changes or requirements using Frontmotion's MSI.

Other features are nice, but are not required to do a large scale deployment.

Using a slippery slope argument of what might be desired by some people in the future is not good reasoning.
(In reply to comment #139)
> Using a slippery slope argument of what might be desired by some people in the
> future is not good reasoning.

You misinterpreted the intent behind my questions. Comment 135 asserted that simply generating an MSI wouldn't necessarily be useful for large scale deployments. I was asking if that assertion was true. I've been consistent in saying that if it's low effort, building an MSI would be a good thing to do. But the cost of the effort needs to be balanced against the usefulness of the MSI towards its ultimate purpose of enabling large scale rollouts.

Comment 141

11 years ago
(In reply to comment #140)
> You misinterpreted the intent behind my questions. Comment 135 asserted that
> simply generating an MSI wouldn't necessarily be useful for large scale
> deployments. I was asking if that assertion was true. I've been consistent in
> saying that if it's low effort, building an MSI would be a good thing to do.
> But the cost of the effort needs to be balanced against the usefulness of the
> MSI towards its ultimate purpose of enabling large scale rollouts.

While certainly not perfect for those that want to be able to force settings such as proxies and privacy options its certainly a good start and makes enterprise deployment much easier especially for security updates where you can in 2 minutes using Group Policy ensure that everyone will be updated to the latest security update. Prior to using the 3rd party MSI out organisation had everything from v1.0 right through to 1.5.0.x and just about every version in between

Comment 142

11 years ago
(In reply to comment #140)
> You misinterpreted the intent behind my questions. Comment 135 asserted that
> simply generating an MSI wouldn't necessarily be useful for large scale
> deployments. I was asking if that assertion was true. I've been consistent in
> saying that if it's low effort, building an MSI would be a good thing to do.

There's no definitive answer to that because of the range of scenarios.  However, as a guide, it really has to do with numbers, and that bearing on the TCO of Firefox within an enterprise environment.

If a company has 10 computers, they don't need an MSI.  They just have someone go round installing it.
If a company has tens to hundreds of computers, then could well need an MSI only.  If they then need to change a preference, they can then email out to everyone and ask them to do it manually, and then pick up the stragglers through user support.
Once you get into hundreds, thousands and tens of thousands of computers, that doesn't become practical, and you need to be able to both control the version and the preferences.  At this point, you need the ability to centralise the preference control.

Obviously, the above is no rule and I'm sure there are many exceptions depending on their scenario, but that generally fits.

So, if MoCo wanted to go after the SMB market, creating just an MSI would be certainly enough.  Much of what I said in comment 135 was targetted towards the larger enterprise (although, in any market size, I stand by what I said about EOL lengths).  I would also add that it is very much more likely that a larger organisation will have resident experts in repackaging applications as MSIs.  Therefore, it seems to me that the MSI should take the precedence in terms of importance.  Leave the GPO support issue in #267888 (which this call blocks).

Comment 143

11 years ago
This is an idea whose time has come. IE7 has been released, but large enterprise IT departments cannot deploy it as a safer/better general browsing tool for their users because of numerous internal applications that are incompatible with anything but IE6.

Unlike IE7, Firefox runs happily side-by-side with IE6, giving corporate IT the best of both worlds: a stable, safe, modern web browser for general browsing and use on newer, more egalitarian systems, while retaining IE6 on the desktop for intranet applications that were poorly-developed and could not be fixed in time for IE7.

But to do this, they need deployable packages. Reduce the friction of installation and management and they may give Firefox the time of day.
Depends on: 302046
(Reporter)

Comment 144

10 years ago
They have MSI builds at http://www.frontmotion.com/Firefox/index.htm

The site will actually build an MSI package to your specifications.  

To any other commenters, this isn't a question of whether this should happen, its a question of when it will happen.  Someone just needs to step up and do it.
Blocks: 388257
No longer blocks: 388257

Comment 145

10 years ago
Created attachment 278253 [details] [diff] [review]
a more complete msi installer

It's integrated as far as I can get it.
This requires MakeMSI
To build
cd to objectdir/browser/installer/windows
make msiinstaller
then open a windows command prompt in objectdir/browser/installer/windows/msigen and type mm firefox.mm P
Attachment #172077 - Attachment is obsolete: true
Attachment #172078 - Attachment is obsolete: true
Attachment #175803 - Attachment is obsolete: true
Attachment #278253 - Flags: review?(robert.bugzilla)
Comment on attachment 278253 [details] [diff] [review]
a more complete msi installer

Some notes and questions.
How are these strings localized?
On the trunk we only support Win2K and above.
application/x-xpinstall;app=firefox never worked and has been removed.
gopher shell integration has been removed.
-osint has been added to the open command for shell integration.
There are additional dirs under the appdir than the ones in this patch.
Last I checked we cannot distribute flash legally.
When attaching patches don't include diffs of binary files. Instead add them as separate attachments.
Attachment #278253 - Flags: review?(robert.bugzilla) → review-

Comment 147

10 years ago
Strings can be localized via an tab delimited file.  Support is easy, but there are no translations.  The MSI can be chaned to support Win2K and above installs easly.  xpinstall regkey will be removed. ditto gopher. -osint will be added. additional dirs?  It only adds localized and nonlocalzied.  Those other lines are there for testing.  It doesn't add flash, that's commented out.  how will people know where to put those binary files?
Blocks: 305797
(Reporter)

Comment 148

10 years ago
Is it possible for this file to be generated so that it is
1) localizable
2) picking up other build options such as product name
3) picking up other build options such as built extentions
4) whatever other changes that are going into the current installer

That way we only have to make changes in one place.

Comment 149

10 years ago
MAKEMSI is based on the PPWIZARD preprocessor (http://dennisbareis.com/ppwizard/introductiontoppwizardhtmlpreprocessor.htm), it can therefore execute external commands, parse results, read files or environment variables etc.

I know nothing about where this info is so can't really say more, just it can be done...

Comment 150

10 years ago
Created attachment 299877 [details] [diff] [review]
WiX-based XULRunner msi/msm (proof of concept)

make -C @obj-XR@/xulrunner/installer installer
with this patch will create a working 'xulrunner-$version.$lang.win32.msi' in @obj-XR@/dist and '*.msm' in @obj-XR@/xulrunner/installer/windows

I understand, that this patch is only worth r-. However, it already demonstrates certain cool features:
* it is dynamically generated;
* w/out a single UI line of code, it will ask LUA for privilege escalation. it will install in per-user mode, if no admin password provided;
* .msm module can be reused in other applications. This is fascinating: I have been able to install-remove stand-alone xulrunner, firefox-on-xulrunner (only files) and a custom XR app (with a desktop shortcut) in any order w/out breaking anything. Each of them contains xulrunner module with system-wide registration.
Attachment #299877 - Flags: review?

Comment 151

9 years ago
Created attachment 306248 [details] [diff] [review]
WiX-based XULRunner msi/msm

With this patch, 'make installer' produces xulrunner.msm and a cfg file for it, which can be included in wix configuration for applications.

WIX_FLAGS and MSI_EXTRA makefile variables allow to add dependencies to application's main wix file. After building msm for xulrunner-1.9b3 with this patch, I was able to create msi packages for my application with one command per package:
make -f check.mk installer
make -f check.mk installer AB_CD=ru

Application configuration is available here:
http://repo.or.cz/w/abstract.git?a=tree;f=installer/windows
http://repo.or.cz/w/abstract.git?a=blob;f=check.mk
Attachment #299877 - Attachment is obsolete: true
Attachment #306248 - Flags: review?
Attachment #299877 - Flags: review?

Updated

9 years ago
Flags: blocking-firefox3?
This will not block the final release of Firefox 3.
Flags: blocking-firefox3? → blocking-firefox3-

Comment 153

9 years ago
Your code looks interesting Sergey, however I am a Jr Programmer and I'm having some problems running it. Can you please elaborate on what how to run this script (ie. What requirements do I need, What install dir).

Thanks

Comment 154

9 years ago
You'll need:
* msys build environment for mozilla (mozilla-build);
* wix 2.0 from http://wix.sourceforge.net/releases/2.0.5805.0/wix2-binaries.zip;

To create msm/cfg/msi:
1. extract wix zip somewhere (/c/wix in this example)
    mkdir /c/wix
    cd /c/wix
    unzip -x /path/to/wix2-binaries.zip
2. add wix directory to your $PATH:
    export PATH="$PATH:/c/wix"
3. apply my patch to mozilla tree you want to pack (works with 1.9b4 and later):
    cd /path/to/mozilla
    patch -p1 < /path/to/patch
4. build mozilla

5. cd to objdir, if any.

6. create xulrunner msm/cfg/msi:
    make installer

This sequence will produce xulrunner.msi in dist/ and xulrunner.msm in xulrunner/installer/windows/. The MSM will have a companion CFG file, which can be used to package xulrunner with XUL applications. I use it to package my Abstract project. The Makefile is here:
http://repo.or.cz/w/abstract.git?a=blob;f=installer/windows/Makefile.in 

Comment 155

9 years ago
Created attachment 313598 [details] [diff] [review]
WiX-based XULRunner msi/msm v3

This patch fixes a small bug and further improves packaging process.

With the previous patch, 'make' was triggering msi package creation. This is now fixed.

Locale-specific files are now packed into a separate MSM module, which allow to create MST transform packages later.
Attachment #306248 - Attachment is obsolete: true
Attachment #313598 - Flags: review?
Attachment #306248 - Flags: review?
Blocks: 308659

Comment 156

9 years ago
My day of programming are just about at an end.  
I would really apreciate it if you could make an ADDON for all parts of the mozilla family.  Then I would be able to try it and see if it might fix my broken Thunderbird! See bug 450421 .
Version: unspecified → Trunk
Comment on attachment 313598 [details] [diff] [review]
WiX-based XULRunner msi/msm v3

The patch is quiet a bit old but can you have a look at this Robert?
Attachment #313598 - Flags: review? → review?(robert.bugzilla)
Comment on attachment 313598 [details] [diff] [review]
WiX-based XULRunner msi/msm v3

It is a good start... as stated before in comment #146... how will this be localized?
Attachment #313598 - Flags: review?(robert.bugzilla) → review-
(In reply to comment #158)
> It is a good start... as stated before in comment #146... how will this be
> localized?

Looks like there are .wxl files which group all needed strings:
http://wix.mindcapers.com/wiki/Localization

The question was in relation to our localization and our build system. This currently requires the use of .properties or .dtd files. I had to do this when implementing the NSIS installer and this would need to be done for MSI.

Comment 161

9 years ago
(In reply to comment #157)
> The patch is quiet a bit old but...

The patch worked at about fiefox3 beta5, and it contains build-system-only changes. AFAICT, it should be working with 3.0.0.x branch without major changes.

(In reply to comment #157)
> how will this be localized?

I am using the patch from attachment 313598 [details] [diff] [review] to produce MSM for non-localizable part of libxul. MSM is later used to package my XUL app for 2 locales en_US and ru. If both are installed, the libxul is shared. Anyone interested may check at http://repo.or.cz/w/abstract.git?a=tree;f=installer/windows for the build-system code on the app side.

I am really interested in getting this bug resolved.
(In reply to comment #161)
>...
> (In reply to comment #157)
> > how will this be localized?
> 
> I am using the patch from attachment 313598 [details] [diff] [review] to produce MSM for non-localizable
> part of libxul. MSM is later used to package my XUL app for 2 locales en_US and
> ru. If both are installed, the libxul is shared. Anyone interested may check at
> http://repo.or.cz/w/abstract.git?a=tree;f=installer/windows for the
> build-system code on the app side.
> 
> I am really interested in getting this bug resolved.
The localization will either need to be done with .properties or .dtd files unless Axel (l10n at mozilla dot com) agrees to a new format. To get this resolved the MSI's will need to be localized and the patch will need to include how this will be accomplished.

Comment 163

9 years ago
(In reply to comment #162)
> The localization will either need to be done with .properties or .dtd files
> unless Axel (l10n at mozilla dot com) agrees to a new format. To get this
> resolved the MSI's will need to be localized and the patch will need to include
> how this will be accomplished.

A few points:
1. .properties and .dtd files are usually jarred into $(AB_CD).{jar|manifest} pair.

2. libxul produces such a pair, and I am also using such a pair in my application. The names (en_US.*) are the same but locations differ.

3. The packaging workflow of my app looks like this:
* build libxul with AB_CD=en_US;
* package into MSM:
** localization-independent part of libxul (1);
** en_US part of libxul (2);
* build my app with AB_CD=en_US;
* package into MSM:
** localization-independent of my app (3);
** en_US part of my app (4);
* build my app with AB_CD=ru;
* package ru part of my app into MSM (5);
* assemble MSI for en_US from (1), (2), (3), (4);
* assemble MSI for ru from (1), (2), (3), (5).

I am not using any language specific symbols from libxul, so (2) is fine for the ru locale of my app. This most likely isn't the case for firefox, and this is the only part that remains to be done.

Comment 164

9 years ago
I'm rather clueless about what the UE is here, but we're not going to go with a new localizable format. If we need wxl files, we should preprocess a DTD file into the wxl file. As we're talking plain xml, AFAICT, this is really just using the preprocessor to include a DTD with the localizable strings into a generic xml. That's hoping that the xml parser that reads the wxl files groks that. Otherwise, processing a .properties is probably easier.
I might be completely wrong here, but I think you guys are talking apples and oranges:

Sergey, Robert wants the text used in the installer UI to be localized using DTD or .properties files. He is not talking about the text in the application or in the libxul runtime.

(or am I wrong?)

Comment 166

9 years ago
(In reply to comment #165)
> I might be completely wrong here, but I think you guys are talking apples and
> oranges:

Mark, thanks for the comment.

There should be no changes to the application localizable symbols, so we are talking about installer symbols here, right?

If so, the installer is the only consumer of those symbols, right?

And if so, it may make sense to put the symbols directly into installer source file (that is .wxl). Or am I missing something?

Comment 167

9 years ago
We're not going to expose wxl files to our localizers. Whatever you do has to work on either .properties or .dtd files.

Comment 168

9 years ago
... which means, that's what you get at build time. You can do build-time preprocessing to other formats allright, to be used in the actual packaged installer. See comment 164.
note: App Update will also likely need work in that either:

a: the MSI App Update mechanism will need to be implemented for all versions of Windows if possible... this is preferred over b.

b: our existing App Update will need to taught to update the registry entries and anything else required by MSI.

Comment 170

9 years ago
IT IS POSSIBLE, and pretty easy to use DTD's to translate messages the installer provides!

I just managed to easily build an MSI using the latest stable version of WiX, an old wxs file I used for another project once, and a hacked en-US file, which included a DTD file where I actually defined a few entities (for Next and Back buttons).

However, there is a little difference between labels in WiX and XUL, and that difference is that in WiX, you have to define the accesskey within the label, as in "&amp;Next". 

BTW, *.wxl files are meant for localization of WiX, so I don't really think allowing localizers to work on that would be a huge risk. However, when using a DTD, the installer would not even compile if some entity is missing. Plus, the format of the file to localize would also be familiar for the localizers. So using DTD's makes sense too.

Comment 171

9 years ago
(In reply to comment #164)
IT IS POSSIBLE, and pretty easy to use DTD's to translate messages the installer provides!

I just managed to easily build an MSI using the latest stable version of WiX, an old wxs file I used for another project once, and a hacked en-US file, which included a DTD file where I actually defined a few entities (for Next and Back buttons).

However, there is a little difference between labels in WiX and XUL, and that difference is that in WiX, you have to define the accesskey within the label, as in "&amp;Next". 

BTW, *.wxl files are meant for localization of WiX, so I don't really think allowing localizers to work on that would be a huge risk. However, when using a DTD, the installer would not even compile if some entity is missing. Plus, the format of the file to localize would also be familiar for the localizers. So using DTD's makes sense too.

Comment 172

9 years ago
Whoops, sorry for double-committing... :(
Rimas, do you have an URL which gives an example or can you even supply one? I believe that it will help a lot. So probably someone could do a similar thing for Firefox and Thunderbird installers.

Comment 174

9 years ago
Well, actually, I have deleted those files after proving to myself it was possible, because I worked it out with version 2 of WiX, but Wix 3 (currently at pre-release state) didn't like the installer source at all, and I eventually decided not to waste my time... 

Anyway, what I did was:
* create a DTD file that defines a few entities;
* create a WXL file which references a DTD file and uses entities defined in it;
* compile a MSI file using the WXL file as a localization source.


Anyway, I have already tried to reference the DTD and use its entities in the same way in the WXS file (With WiX 3), and it doesn't work. I'm not sure if it's a bug or intended behavior, but when candle.exe transforms the WXS file to WIXOBJ file, it escapes ampersands, so &installerString; becomes &amp;installerString; (meanwhile &amp; remains untouched). I'll try to play with the WXL file again, and if that works out, I'll post zipped results here.

Comment 175

9 years ago
Created attachment 352091 [details]
An example of referencing DTD's from WXL file

Here's an example that works with WiX 3. As you can see, the main hackery has been done in loc.wxl.  I couldn't find a WixLocalization DTD, so I just recreated the subset that I needed of it.

To compile the installer, just edit paths in build.bat and loc.wxl, then run build.bat.

The only problem is that I referenced DTD's by full path. That's lame, and should be easy to fix. One of the most obvious ways to fix it is to define a variable containing the path required, and then use it as a base. Also, I'm not sure what exactly the -cultures switch changes in light.exe (assuming that we translate all installer strings ourselves).
Blocks: 474088
Blocks: 274624

Comment 176

8 years ago
This bug has now been around for quite some time and Rimas is very close to a solution. Question is what will happen after we're done creating build scripts?

Will we start delivering out of cycle or wait for Firefox.next? Who would responsible for installing the scripts on the server? Would we provide MSIs for nightly builds?

Personally, I think we should deliver these ASAP and along the current installer, which is still the best solution for normal consumer installations. Especially European customers are literally crying about not being able use Firefox in corporate and equally important educational environments (at least that I can confirm from personal experience).

I'll look into setting up a clean build script tonight, using the normal installer DTDs for localization (I think I should find any necessary definitions in there, so that we don't need any additional definitions).

As far as I know the update mechanism by now is able to identify locked-down environments and skip updates, so there shouldn't be any problem there. The only remaining issue would be configurability via the registry (I'll file a separate bug on that), but I think we can safely provide that lateron. Also, it might be a good idea to provide update packages as well, but we'll see about that later.
I'd love to provide these from Mozilla but there are still several questions / issues that will need to be addressed such as comment #169 before this is provided by Mozilla. Also note that providing an MSI for Firefox has been given priority for Firefox.next.

(In reply to comment #176)
> This bug has now been around for quite some time and Rimas is very close to a
> solution. Question is what will happen after we're done creating build scripts?
Besides the build tools which would added to MozillaBuild the scripts should only need to be checked in.

> Will we start delivering out of cycle or wait for Firefox.next?
It will likely be part of Firefox.next.

> Who would responsible for installing the scripts on the server?
The scripts would typically be checked in as mentioned previously.

> Would we provide MSIs for nightly builds?
Typically an MSI app has an ID which would prevent installing a nightly, beta, or official (for that matter multiple official releases) side by side on the same system. Some options are having a separate ID for nightly, beta, and official which would solve this problem for the most part but not for every case. I think this question is better answered after how updates are going to work has been figured out.
Just in case lets put it on the radar.
Flags: blocking-firefox3.6?

Comment 179

8 years ago
Thanks.

About the updates: Without any knowledge of AD, I'd say that the issue would probably mostly go away when group policy guidelines are implemented. When admins can enable/disable the Firefox internal update mechanism, they can either allow the application to update itself and be done with it, but with less control or they can disable it and push the updates themselves. Firefox would just count as a single application, no matter what version, and the MSI would completely overwrite any existing installation. That way there's no conflict when an admin allows automatic updates.
MSI's keep track of the files an app has installed and our app update mechanism does not update the files installed by an MSI which will break the MSI installation.

Comment 181

8 years ago
Dang. So we're stuck with disabling autoupdate anyway. Would we need to do anything but setting app.update.auto false on the default install for that? Anyway, we're back at the group policies.
What I am planning on doing is figuring out how to make Win32's app update use msp's.

Comment 183

8 years ago
(In reply to comment #177)
> I think this question is better answered after how updates are going to
> work has been figured out.

As many people here have pointed out, the MSI architecture doesn't work correctly if files are patched without the MSI databases being updated - in other words, MSI files need MSI or MSP updates. 

I might be wrong, but my assumption would be that administrators would use MSI to initially deploy Firefox using an MSI installer then (in most cases) rely on Firefox itself for automatic security patches. It would be similar to how other software is deployed - much of the time IT just wants to get the software out there and usable to a large number of machines, not have to manually redeploy new versions as each security update gets released.

The v6.X versions of Windows can assist a bit here - signed MSI files can have signed MSP patches applied to them by standard users unless the system administrator disables the behavior via group policy.

Dual installers can be quite a bit of a pain - I remember dealing with a large number of headaches trying to deploy faulty VPN MSI packages when the "classic" version worked. Duplicating the installer means double the work at all levels - two installation packages to maintain, two patch channels/paths, twice as much testing, etc. In my experience what tends to happen is the MSI ends up being thought of as the "secondary" installer and is a bit of an afterthought - as a result, quality tends to suffer. This may no be the case with a Firefox MSI, but in every other case I've seen "dual installers" they're nothing but trouble.

MSI is a very stable technology - it might be worth considering switching Firefox entirely onto it for the Windows platform and have the 3.5->next upgrader migrate people onto an MSI based tech.

More testing up front (careful to mind the component rules and upgrade scenarios, etc) - but in the long run I think everyone wins. One set of code to maintain, standard user updates without UAC on Vista and Windows 7, and enterprise deployments. 

At work here we used a bootstrapper deployed via our legacy update system to launch into an MSI. All updates after that point are trivial MSP patches - I imagine something similar could be developed for Firefox.

Comment 184

8 years ago
Most of the time when a sysadmin deploys MSI packages with active directory, the users won't have rights to update Firefox themselves.  

So I think, that by default the MSI package should have the auto update feature turned off system wide.  

The option to enable the auto update should still exist on the feature selection screen for those who manually run the MSI (or use a transform).  Open Office and Java have similar capabilities.
(In reply to comment #183)
That is pretty well aligned with my thoughts on MSI. My main concerns being that:
a. localization for the MSI is the same as it is for Mozilla in that it uses either dtd or properties files.
b. update process is figured out as noted previously especially in regards to trunk, branch, other repo builds for nightly and beta as well as official builds.

(In reply to comment #184)
> Most of the time when a sysadmin deploys MSI packages with active directory,
> the users won't have rights to update Firefox themselves.  
This will most likely just be an option on install and / or via group policy
No longer blocks: 241532, 474088
No longer depends on: 229706
Depends on: 386740
No longer depends on: 302046

Comment 186

8 years ago
(In reply to comment #185)
> (In reply to comment #183)
> That is pretty well aligned with my thoughts on MSI. My main concerns being
> that:
> a. localization for the MSI is the same as it is for Mozilla in that it uses
> either dtd or properties files.

Possible, see attachment 352091 [details]. I think by adding a few new environment variables at compile time, we should even be able to get rid of this line:
<!ENTITY installerCulture "en-us">
in installer.dtd

> b. update process is figured out as noted previously especially in regards to
> trunk, branch, other repo builds for nightly and beta as well as official
> builds.

I think you pretty much covered it in Comment 177: the solution is having a separate ID for nightly, beta, and official.

And those who would want to have two or more released versions of Firefox at the same time, could simply use zip tarballs that Mozilla provides even now to install older versions.

> (In reply to comment #184)
> > Most of the time when a sysadmin deploys MSI packages with active directory,
> > the users won't have rights to update Firefox themselves.  
> This will most likely just be an option on install and / or via group policy

I hope it won't be disabled by default. An option at install time would be the best. Furthermore, I think we could just look at how default options are deployed in other applications that use MSI. I'm pretty sure there is a mechanism to do that.
Blocks: 52052
(In reply to comment #186)
> (In reply to comment #185)
> > (In reply to comment #183)
> > That is pretty well aligned with my thoughts on MSI. My main concerns being
> > that:
> > a. localization for the MSI is the same as it is for Mozilla in that it uses
> > either dtd or properties files.
> 
> Possible, see attachment 352091 [details]. I think by adding a few new environment
> variables at compile time, we should even be able to get rid of this line:
> <!ENTITY installerCulture "en-us">
> in installer.dtd
Yes, I've seen it and believe it is possible. The reason I raise it as a concern is that this is a firm requirement for localization.

> > b. update process is figured out as noted previously especially in regards to
> > trunk, branch, other repo builds for nightly and beta as well as official
> > builds.
> 
> I think you pretty much covered it in Comment 177: the solution is having a
> separate ID for nightly, beta, and official.
> 
> And those who would want to have two or more released versions of Firefox at
> the same time, could simply use zip tarballs that Mozilla provides even now to
> install older versions.
I see this as the fallback position if no better way is found to be able to do this.

> > (In reply to comment #184)
> > > Most of the time when a sysadmin deploys MSI packages with active directory,
> > > the users won't have rights to update Firefox themselves.  
> > This will most likely just be an option on install and / or via group policy
> 
> I hope it won't be disabled by default. An option at install time would be the
> best. Furthermore, I think we could just look at how default options are
> deployed in other applications that use MSI. I'm pretty sure there is a
> mechanism to do that.
The burden will be placed upon the admins distributing Firefox but we will make the burden very small.

Comment 188

8 years ago
(In reply to comment #187)
> > > (In reply to comment #184)
> > > > Most of the time when a sysadmin deploys MSI packages with active directory,
> > > > the users won't have rights to update Firefox themselves.  
> > > This will most likely just be an option on install and / or via group policy
> > 
> > I hope it won't be disabled by default. An option at install time would be the
> > best. Furthermore, I think we could just look at how default options are
> > deployed in other applications that use MSI. I'm pretty sure there is a
> > mechanism to do that.
> The burden will be placed upon the admins distributing Firefox but we will make
> the burden very small.

I agree with this.
If the users are not allowed to install firefox, they should also not be able to update FF.

That way the admins can decide when/if they wish to upgrade to a new version.
And just adding the new msi to the ADS and marking it as update for the old package ist the way it is intended to work.

Comment 189

8 years ago
(In reply to comment #184)
> Most of the time when a sysadmin deploys MSI packages with active directory,
> the users won't have rights to update Firefox themselves.  
> So I think, that by default the MSI package should have the auto update feature
> turned off system wide.  

Seconded. I am a sysadmin who deploys lots of MSI files onto a school network
using Group Policy, and this is exactly the case for us. Whenever a new version
of Flash/Shockwave/Java/QuickTime comes out, we deploy the new MSI manually,
with auto-updates switched off. Means that we have complete control of what's
installed on the network, and can do proper testing etc before the updates get
deployed.

I should also say (in reply to comment #169) that trying to update the registry
entries etc created by MSI is a very bad idea - if you get it even slightly
wrong you can cause a lot of problems. Best to stick to a complete
uninstall/reinstall for the time being, and then provide an option for MSPs at
a later date.
The default will be to leave auto update on since the MSI will be used by regular users as well. The admins deploying the MSI will be able to disable app update as noted in comment #187.

I'm aware that trying to update the registry entries is a very bad idea and plan on using .msp's for patching which will update the registry. Comment #169 was to note that this needed to be done and gave a couple of options on how to do it so anyone that supplied a patch for this bug realized that this is a requirement.

Comment 191

8 years ago
Just a reminder from older discussions (comment #134 and #135) an easy way to set the homepage is really necessary. That is a deal breaker in many organizations, including the one where I work...
(In reply to comment #188)
> I agree with this.
> If the users are not allowed to install firefox, they should also not be able
> to update FF.

IIRC, our update mechanism is disabled when the user you're running as doesn't have write access to the application directory anyway, so if Firefox is installed by an admin and run by a normal user, updates will not be attempted.
(In reply to comment #192)
> IIRC, our update mechanism is disabled when the user you're running as doesn't
> have write access to the application directory anyway, so if Firefox is
> installed by an admin and run by a normal user, updates will not be attempted.
With MSI's we will most likely be using MSP's for patching and one of the goals will be when the user doesn't have write access they will still be able to update on at least some platforms per comment #183 so this isn't applicable. We will provide the ability to turn it off per comment #187.

Comment 194

8 years ago
(In reply to comment #193)
> (In reply to comment #192)
> > IIRC, our update mechanism is disabled when the user you're running as doesn't
> > have write access to the application directory anyway, so if Firefox is
> > installed by an admin and run by a normal user, updates will not be attempted.
>
> With MSI's we will most likely be using MSP's for patching and one of the goals
> will be when the user doesn't have write access they will still be able to
> update on at least some platforms per comment #183 so this isn't applicable. We
> will provide the ability to turn it off per comment #187.

Most other apps distributed in MSI allow for altering the default behavior in cases like this (for example controlling the app's auto updates functionality) by changing the values of certain predefined properties in the property table of the MSI. The properties in the property table of the MSI can easily be altered by the admin by simply setting a different value on the msiexec command line when installing the package, or using a simple MSI editor to edit the MSI, or even more elegantly create a transform (MST) with these specific different settings set.

So if the Firefox MSI could have some AUTOMATIC_UPDATES=1 property defined in the property table of the MSI, coupled with having this property control some custom action, most admins who want to disable this functionality could do this by just changing the property value to 0.

Comment 195

8 years ago
(In reply to comment #194)
> So if the Firefox MSI could have some AUTOMATIC_UPDATES=1 property defined in
> the property table of the MSI, coupled with having this property control some
> custom action, most admins who want to disable this functionality could do this
> by just changing the property value to 0.

Or better yet, use app.update.auto=true like the setting in about:config.

Comment 196

8 years ago
(In reply to comment #195)
> (In reply to comment #194)
> > So if the Firefox MSI could have some AUTOMATIC_UPDATES=1 property defined in
> > the property table of the MSI, coupled with having this property control some
> > custom action, most admins who want to disable this functionality could do this
> > by just changing the property value to 0.
> 
> Or better yet, use app.update.auto=true like the setting in about:config.

Are you sure periods are allowed in MSI property names? I cannot find anything that would suggest that they are allowed. Furthermore, all standard MSI properties use uppercase and underscore, and so do the custom properties of all applications I have encountered. See for example http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Automatic_Installation_on_Windows#MSI_Properties.

Comment 197

8 years ago
(In reply to comment #196)
> Are you sure periods are allowed in MSI property names? I cannot find anything
> that would suggest that they are allowed. Furthermore, all standard MSI
> properties use uppercase and underscore, and so do the custom properties of all
> applications I have encountered. See for example
> http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Automatic_Installation_on_Windows#MSI_Properties.

You are correct about lowercase letters in public properties, but periods are allowed in all properties. More info:
http://msdn.microsoft.com/en-us/library/aa371245%28VS.85%29.aspx

How about:
APP.UPDATE.AUTO=1

Comment 198

8 years ago
(In reply to comment #197)
> You are correct about lowercase letters in public properties, but periods are
> allowed in all properties. More info:
> http://msdn.microsoft.com/en-us/library/aa371245%28VS.85%29.aspx
> How about:
> APP.UPDATE.AUTO=1

Given that each property would need to be manually programmed into the MSI, it might be better to go with a more standard MSI convention for property naming. 

I don't think usability will suffer - it should be fairly obvious to most admin's looking at the MSI property table. It might even reduce confusion, given that an MSI Properties != Firefox settings (in other words, I doubt it makes sense to program the MSI to support the arbitrary configuration of any Firefox setting at install time)
The last several comments are all bikeshedding[0], and I'm sure all their contributions would easily and trivially have been figured out in the work of writing a patch (or can be made after a patch manifesting the problem is actually provided).  Please don't comment unless you have a meaningful technical contribution -- anybody can argue naming, and naming that's forbidden is an especially easy problem to understand and fix.

0. http://www.bikeshed.com/
Rob: how far away are we on this? Not gonna hit 1.9.2, and I'm not sure it makes sense to aim for 1.9.3 but wanted a rough sense of feasibility.
blocking2.0: --- → ?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
With the short cycles for 1.9.2 and 1.9.3 I highly suspect this won't make it until after 1.9.3 especially since this will affect app update as well.
Is there any way we could help to speed up this bug?

For corporate deployment is really needed, and I'm sure lots of sysadmins would install Firefox today in their companies if they just have to drag and drop the msi package ;)
I've been working on this a bit lately.  I've taken Sergey's patch and updated it to run on the Wix 3.0 toolchain and for Firefox instead of Xulrunner.  I'm also confident that we can solve the l10n concerns.  I haven't played with the app update stuff too much though.  I would post my work-in-progress, but the laptop I develop on is currently in another time zone for repairs :-(
Created attachment 418915 [details] [diff] [review]
MSI with WiX WIP 1

This diff creates an MSI using WiX for Firefox.  It obviously has a long way to go, but it provides equivalent functionality to the packaged zip distribution (i.e., it runs).

Notes:

1. It's obviously missing stuff like Add/Remove Programs support, a real GUI, etc.
2. The component GUIDS that are generated are stable, so this sort of MSI can be used to build patches
3. I used heat (the WiX harvester utility that does the heavy lifting here) on installer-stage/nonlocalized and installer-stage/localized to build two separate include files.  This is fragile (you need to specify the directory structure manually, and use XSLT to rework the generated WiX files) and unnecessary (no real benefit of having separate ComponentGroups as far as I can tell) so I'll probably switch to using the result of make package in the next draft.
Assignee: nobody → me
Created attachment 419518 [details] [diff] [review]
MSI with WiX WIP 2

Some cleanup over WIP 1, includes Add/Remove Programs Support that is branding aware.
Attachment #418915 - Attachment is obsolete: true
I've been working on some UI stuff for the installer and will have a much more thorough patch in a week or two.  In the meantime I did some tests on size.  I wrapped the MSI in a 7z self extracting executable as the regular installer is.  Obviously the MSI isn't quite fully functional, but the size shouldn't increase dramatically as features are added (especially since the MSI database is dwarfed by the actual files) though some size may be contributed by the branding images.

This is for a debug trunk build.

Type                                Size
ZIP                                 12.8 MB

NSIS Installer                      8.71 MB

MSI (Cabinet not embedded in MSI)   9.72 MB

I believe the difference is primarily due to the compression used (I didn't run the compression the scripts run, just used the 7zip desktop program with the defaults) because the NSIS installer executable is 472 KB and the MSI database is ~300 KB so far so the overhead is not bad yet (keep in mind this is sans UI in the MSI).
Hi Kyle, I appreciate you taking this on.

The main reasons that the NSIS installer is wrapped in a 7zip self extracting archive is to lower the file size and to make repackaging of localized builds simple. It isn't a requirement as long as these two requirements are met.

How are app updates going to be handled with MSI installations?

How are people going to be able to install multiple builds side by side?

Thanks

Comment 208

8 years ago
Robert,

Speaking as a network admin, I don't care about multiple builds side-by-side in 99% of my installs.  I also don't care about auto-updates.

The whole point of getting the MSI out there is so admins like me who manage 700 desktops can easily push out an identical copy of Firefox to every machine.

If someone needs some weird one-off setup with multiple builds, I can manage their machine separately.

I also don't want FF automatically downloading updates on hundreds of computers at the same time.  *I* will download the updated MSI from the Firefox website, test the update with a select group of people, and push it out on my schedule.

To be blunt, the main reason I am running Internet Explorer on 800 desktops instead of Firefox is because I can't easily deploy Firefox.  I can easily choose via Microsoft Software Update Services when to install updates to IE.

The second (and much lesser) reason is that I can't easily control it via Group Policy to do things like automatically set the home page, lock down plugins, etc...

I don't mean this to sound as harsh as it's probably coming across--but I'd rather have the MSI now even if it doesn't do everything the standard installer does than have to wait another 6 years.  (This bug will have it's sixth birthday in a few days.)

Thank you Kyle for tackling this.  When the MSI comes out, you will have a *lot* of admins that want to buy you a beer... ;)
Aaron, there have been MSI's available for Firefox for years now ( http://www.frontmotion.com/Firefox/ for example ) though they aren't made available by Mozilla due to the app update issue. If Mozilla publishes an MSI without the ability to update and regular users install it then many of them will end up stranded and I highly doubt that will be acceptable. To be blunt I would love it if we had an MSI distribution.
(In reply to comment #207)
> How are app updates going to be handled with MSI installations?
> 
> How are people going to be able to install multiple builds side by side?
> 
> Thanks

To be straight, I have no idea yet.  It's obviously a big project to tackle.  I haven't even taken a look at the app updater code.  My conceptual idea for that is simply to wrap the MSP files in the MAR format and then replace the updater helper executable's guts with "msiexec /p patch.msp".

As far as running multiple builds side by side, what exactly does that mean?  Are we talking about running say 3.5 and Minefield side by side, or running the en-US and AB-CD locales side by side on the same version, or running 3.5.1 and 3.5.7 side by side?  I have no idea if we support the last one, but the first two should not be particularly difficult as long as we keep the upgrade GUIDs managed well (as they are the equivalent of the "channels" that currently exist).  Achieving the third one with working updates could get tricky though, but I'm not sure if we support it and don't really see a use case for keeping an older minor version around.
Application updates can be turned off with a preference. A customized corporate build would contain this preference.

I doubt folks would use the off the shelf MSI.

And most people are aware of the FrontMotion MSIs, but they want official Mozilla MSIs.
What are the characteristics that they want in their MSIs that they would get from "official Mozilla MSIs" but don't from the FrontMotion ones?  Many of our users get their Firefox from contributed builds for OS/2 or Solaris or AIX, which are no more "official Mozilla" than the FrontMotion ones in any useful sense.  It would be helpful to talk about specific characteristics, rather than more general labels, since otherwise -- or even so! -- it may well be that MSIs we host for download won't provide what people are looking for.

And if people aren't going to use the off-the-shelf MSI, what does that mean about them being official?  If it's a matter of support, we provide that through SUMO for even explicitly non-official Firefox setups, like Iceweasel and such, if the problem seems to be a core issue and the user or their agent can help us determine that.  I don't see how we would provide any more support to someone who tweaked their MSI and got a failure that didn't show up with ours (or FrontMotion's, for that matter).

We do support running any number of builds side by side, be they the same major stream or not.  All of Firefox's application state is and should remain local to the installation area, so if you can install an MSI to an alternate path, then it should be fine.  If you can't, then people using MSIs for anything are inherently boned on this point for any application.

Whatever we do with GUIDs, I think it's important that users with MSI installations be able to update from 3.5.x to 3.6 via an MSI-friendly path, just as they would be able to from 3.5.x to 3.5.x+1.
Kyle, using different guids and managing the guid's for trunk, branch, release, etc. is along the lines of what I was thinking as well. It won't support everything that can be done today but I think it is close enough and nightly testers trying to track down a regression range could still use the zip builds. For updates we'll want to use msp's since updates can be applied by non-admin users as long as the cert for the install matches the cert for the update but that problem can be fixed separately after there is the ability to create MSI's but likely before we make MSI's available officially.

Comment 214

8 years ago
"What are the characteristics that they want in their MSIs that they would get
from "official Mozilla MSIs" but don't from the FrontMotion ones?" With the FrontMotion ones you have to trust two entities, with "official" ones only one. By the way: Would it even be possible to sign the MSIs?
(In reply to comment #214)
> By the way: Would it even be possible to sign the MSIs?

That's a prerequisite for non-admin patching on newer Windows versions which is one of the end goals for using an MSI installer, so that is possible and will be done.

Updated

8 years ago
Alias: MSI
As far as GUID management goes, WiX has evolved to the point where it can do 99% of the work automatically.  Pretty much everything in an MSI needs a GUID.  Component GUIDs (99% of the work) can be handled automatically by WiX.  They are generated by the SHA-1 hash GUID algorithm from the component path (version 5?) so they are unique and stable so that patching can work.

Really the only GUIDs we need to handle are the upgrade codes.  An upgrade code is roughly analogous to an "update channel" in Mozilla's system.  In my mind, the nightly builds will have one constant upgrade GUID and each major stable release will have its own upgrade GUID and each branch's tip will have its own upgrade GUID.  Of course these can be tweaked as necessary to fit our needs.

I think we can easily support everything we do today except run the same build side by side, which is still possible, just takes some more work and a dirty hack but it works.  That's difficult because the product code (which WiX will generate at packaging time on our end) needs to be unique on the user's machine (it's a bit more complex than that, but that's more or less how it works).  The canonical way to get around that is to use a bootstrapper that can generate a new product code on the fly if needed.

Shorter: the corporate use case is actually a lot simpler than the end-user use case.

Comment 217

8 years ago
This is the wish list from my employer, in order of importance:

1. Auto updates turned off. (A must since regular users lack privileges to do the update anyway.)

2. Ability to set default start page.

3. Customization of no.2, 4 and 5 must be painless and quick.

4. Setting some default bookmarks.

5. Setting some default extensions.

Comment 218

8 years ago
(In reply to comment #208)

> 99% of my installs.  I also don't care about auto-updates.
> 
> The whole point of getting the MSI out there is so admins like me who manage
> 700 desktops can easily push out an identical copy of Firefox to every machine.
> 
> If someone needs some weird one-off setup with multiple builds, I can manage
> their machine separately.
> 
> I also don't want FF automatically downloading updates on hundreds of computers
> at the same time.  *I* will download the updated MSI from the Firefox website,
> test the update with a select group of people, and push it out on my schedule.

Firefox has a very good trackrecord concerning updates if you ask me. This is because of those automatic updates.

So if you do want to do updates on your timeframe in your organisation.

How do you get notified about updates ?

Comment 219

8 years ago
I'd also like to be able to disable auto-updates in the MSI.

(In reply to comment #218)
> Firefox has a very good trackrecord concerning updates if you ask me. This is
> because of those automatic updates.

I'm not concerned with Mozilla's track record, I'm concerned with when the updates are run.  I have several school labs with machines that are "frozen" so they boot in the same state every time.  If Firefox were doing auto-updates, it would download and install the update every time someone started it.  With MSI updates, I could have the updates installed in the nightly maintenance window.

> How do you get notified about updates ?

I get notified about updates because the copy of Firefox on my machine doesn't have updates disabled.
Created attachment 420438 [details] [diff] [review]
MSI with WiX WIP 3

Proof of concept for l10n of the installer.  We can run the simple perl script l10nconvert.pl on a .properties file to get the XML based format WiX needs for l10n of the installer UI.  Obviously the UI is about 1/10th baked but if you set the UI level to none or basic this should install fine.

I'm going to continue working on the UI (I'm cloning the NSIS UI, though I don't know if we have any particular attachment to that.  None of the built in WiX UI choices seem to fit our needs well, they all have lots of overkill in license agreement screens, feature trees, etc.) over the next few days and the weekend.
Attachment #419518 - Attachment is obsolete: true
(In reply to comment #220)
>...
> Proof of concept for l10n of the installer.  We can run the simple perl script
> l10nconvert.pl on a .properties file to get the XML based format WiX needs for
> l10n of the installer UI.  Obviously the UI is about 1/10th baked but if you
> set the UI level to none or basic this should install fine.
Is it possible to use dtd's instead? If not, new scripts should be written in python.

> I'm going to continue working on the UI (I'm cloning the NSIS UI, though I
> don't know if we have any particular attachment to that.  None of the built in
> WiX UI choices seem to fit our needs well, they all have lots of overkill in
> license agreement screens, feature trees, etc.) over the next few days and the
> weekend.
There is no attachment to the current UI but there is a desire to simplify the installer / lessen the number of pages where possible. For example, the first page the next button would read install which would start the install and there would be a customize button in the body of the page to allow customization.
(In reply to comment #221)
> (In reply to comment #220)
> >...
> > Proof of concept for l10n of the installer.  We can run the simple perl script
> > l10nconvert.pl on a .properties file to get the XML based format WiX needs for
> > l10n of the installer UI.  Obviously the UI is about 1/10th baked but if you
> > set the UI level to none or basic this should install fine.
> Is it possible to use dtd's instead?
use dtd's without preprocessing that is.
(In reply to comment #222)
> (In reply to comment #221)
> > (In reply to comment #220)
> > >...
> > > Proof of concept for l10n of the installer.  We can run the simple perl script
> > > l10nconvert.pl on a .properties file to get the XML based format WiX needs for
> > > l10n of the installer UI.  Obviously the UI is about 1/10th baked but if you
> > > set the UI level to none or basic this should install fine.
> > Is it possible to use dtd's instead?
> use dtd's without preprocessing that is.

I believe so.

I take it python is preferred to perl for the other scripts as well?
(In reply to comment #223)
> python is preferred to perl for the other scripts as well?

YES!
(In reply to comment #223)
>...
> I take it python is preferred to perl for the other scripts as well?
Yes but we typically don't convert them from perl unless the perl script requires significant changes.

Updated

8 years ago
Status: NEW → ASSIGNED
OK, understood.  I'll go back and convert the perl to python at some point.  I'm going to keep hacking away at this this weekend and see how far I get.  Using DTDs for l10n is definitely possible (with nothing funky on the DTD side) using Rimas's example.  I going to try to hack together at least a proof of concept for updating with MSPs or doing side by side installations (probably the former).  I'll post an updated WIP sometime next week with the results.
I've also been thinking a bit more about how to handle l10n repacks.  From what I read in the build scripts (please correct me if I'm wrong) the process goes something like:

1. Build en-US build appropriately
2. Package the en-US build into a .exe installer
3. For non-en-US locale ab-CD
   a. Open up the installer
   b. Rip out all the en-US components
   c. Insert all the ab-CD components (including the new setup.exe)
   d. Sew the installer back together into a single exe
4. Enjoy your new localized installer

The problem with doing it the current way is that there is no real way to accomplish step 3b.  This is because

1) Files in an MSI are stored in a cabinet file, which makes them difficult to remove and replace.
   a) It has no directory structure in an MSI (i.e. the directory structure is stored only in the MSI database and not in the cabinet file)
   b) It is inaccessible to the tools in our build infrastructure (7zip can read them but not write them, don't see any other tools that can either).
2) The final MSI database itself will contain localized information which is not easily changed, and regenerating the entire MSI from scratch each time would defeat the purpose of "repacking". 

The way that seems most natural to do this with an MSI is.

1'. Build en-US build appropriately
2'. Package the non-localized components into an MSI
3'. For a locale ab-CD (including en-US)
    a. Package the localized components into an Merge Module
    b. Merge the MSI produced in step 2 with the Merge Module
4'. Enjoy your new localized installer

We wouldn't be "repacking" per se because no unpacking would ever occur.  We would still avoid building the entire app from source for each locale though, which from my understanding is the goal.

Thoughts from Robert, Axel, et al.?
That sounds ideal... there is no requirement to unpack / repack and the simplest method that meets the same end results is best.

Comment 229

8 years ago
Created attachment 420705 [details]
Python version of l10nconvert.pl

I converted the l10nconvert.pl to Python for Kyle.

Comment 230

8 years ago
Created attachment 420740 [details]
Python version of brandingconvert.pl

I converted brandingconvert.pl to Python.

By the way, defines without values are not treated differently, i.e.
!define FLAG_WITHOUT_VALUE
would become
<?define FLAG_WITHOUT_VALUE= ?>
(In reply to comment #230)
> Created an attachment (id=420740) [details]
> Python version of brandingconvert.pl
> 
> I converted brandingconvert.pl to Python.
> 
> By the way, defines without values are not treated differently, i.e.
> !define FLAG_WITHOUT_VALUE
> would become
> <?define FLAG_WITHOUT_VALUE= ?>

Thanks Rene!  This was really useful.  I don't think we're doing to have defines without values involved here.  The script worked perfectly with a little makefile hackery to get around a bug in our Python interpreter (see http://mail.python.org/pipermail/python-bugs-list/2007-August/039259.html on why we have to cat the input)

Comment 232

8 years ago
(In reply to comment #227)
> 1'. Build en-US build appropriately
> 2'. Package the non-localized components into an MSI
> 3'. For a locale ab-CD (including en-US)
>     a. Package the localized components into an Merge Module
>     b. Merge the MSI produced in step 2 with the Merge Module
> 4'. Enjoy your new localized installer

Kyle, are you sure it is possible to merge MSI with a Merge Module (aka MSM)? When I last checked, it was required to have all components in MSM (wix 2.0).

Comment 233

8 years ago
Regarding approach to MSI design and i18n:

The way I see many third-party packages doing i18n lately is with a master MSI and then some number of MSTs (transforms).  The MSI contains all the language-independent stuff, and then the MST modifies that to include locale-specific stuff.  Sometimes English will be included in the MSI; sometimes English will be just another language (so you always need an MST).  Some front-end to the MSI process (or perhaps custom actions in the MSI itsekf; I haven't delved too deeply) chooses the MSI based on OS locale and/or user input.

If or how this could be integrated into the Firefox build process, I have no idea.  I'm mostly an IT admin; I just dabble in software design.  I've never used WiX.  :(

Regarding updates and maintenance:

The typical application for an MSI (assuming it isn't the only package format used) is a strongly managed environment.  Users don't have administrator rights on their computers.  Software is updated by the IT department, not by end-users.  This is akin to the user-vs-root distinction from *nix land.  Some tool manages installation and updates to deployed MSI.

This can be done with native Windows tools (i.e., you don't need a third-party product).  Active Directory lets you "Assign" an MSI via Group  Policy.  So the admin creates a GPO (Group Policy Object), links it to an OU (Organizational Unit) containing the computers, and then Assigns the MSI to the GPO.  The next time the target computers reboot, they see the GPO and install the MSI, before the user even logs on.  Updates are handled via the same user interface for GPO.  Windows recognizes that a newer MSI for the same product upgrades an older MSI, and handles it appropriately.

This is a *very* common scenario in a corporate environment.  I would dearly love to see an official Mozilla MSI build.  I give many thanks to FrontMotion for their work, but being a third-party thing, they'll unavoidably lag behind the official releases.
(In reply to comment #232)
> (In reply to comment #227)
> > 1'. Build en-US build appropriately
> > 2'. Package the non-localized components into an MSI
> > 3'. For a locale ab-CD (including en-US)
> >     a. Package the localized components into an Merge Module
> >     b. Merge the MSI produced in step 2 with the Merge Module
> > 4'. Enjoy your new localized installer
> 
> Kyle, are you sure it is possible to merge MSI with a Merge Module (aka MSM)?
> When I last checked, it was required to have all components in MSM (wix 2.0).

Sergey, WiX 3.0 provides an MSM equivalent called a wixlib which works around limitations like that at the cost of not being usable outside the WiX toolchain (which isn't a problem here since we consume the wixlibs at merge time)

(In reply to comment #233)
> Regarding approach to MSI design and i18n:
> 
> The way I see many third-party packages doing i18n lately is with a master MSI
> and then some number of MSTs (transforms).  The MSI contains all the
> language-independent stuff, and then the MST modifies that to include
> locale-specific stuff.  Sometimes English will be included in the MSI;
> sometimes English will be just another language (so you always need an MST). 
> Some front-end to the MSI process (or perhaps custom actions in the MSI itsekf;
> I haven't delved too deeply) chooses the MSI based on OS locale and/or user
> input.

Benjamin, this is a common design pattern but it produces a couple issues for us.  From my understanding, transforms can only be applied at installation time so this would entail shipping both en-US and ab-CD files/UI data for each ab-CD locale.  Also, the need to automatically choose the language based on OS locale (while a neat trick for say a DVD deployed application) isn't necessary for us.  Finally, the design of the WiX toolchain makes it difficult to construct an MST without first building the locale package anyways.

As for updates on my part, getting patching working took a lot more effort than I expected (mostly because WiX subscribes to the "code is the documentation" philosophy when it comes to patching).  I've been able to successfully generate a MSP patch (though not a binary patch, that crashed the toolchain but I'm not sure if that was an input problem or a bug in WiX yet).  I haven't waded into the updater yet though.

Also worth noting is that Windows Installer's UI capabilities leave quite a bit to be desired (one example quirk, Windows Installer recreates each dialog causing the taskbar entry to disappear and reappear).  I will post a sample MSI with the UI I've implemented later this week.

Comment 235

8 years ago
(In reply to comment #234)
> Also, the need to automatically choose the language based on OS locale
> (while a neat trick for say a DVD deployed application) isn't necessary for us.

Please no! I, and many other world travelers, may be "located" in a country, but our "language" preferences are still that of our country of origin (e.g., I am an American living in Germany. I prefer English software). Therefore, please don't determine the *language* from the *locale*;...

Determine the language from the OS's language!!!

Apples and apples, if you will. A lot of software gets this wrong. I constantly have to set Windows to location=Germany but Language=English. It's a PITA.

IOW: Don't confuse location with language.

Comment 236

8 years ago
Peter, read up on http://en.wikipedia.org/wiki/Locale, it's not location.

Not that I think that multi-locale is imminent as a installer feature. The one build we do right now installs the set of locales it's shipping with and selects at runtime.
I've hooked up the MSI patching system to the app updater.  If you want to try it out, I've made a build off of today's trunk at http://www.kylehuey.com/moz/msi/msiupdatetest/firefox-3.7a1pre.en-US.win32.msi (The installation UI is only about half done, so among other things, if you install it from the UI it'll go in [ProgramFilesFolder]/Minefield)

You'll need to change the update.xml location (app.update.url.override) to http://www.kylehuey.com/moz/msi/msiupdatetest/update.xml

Once you do that, if you check for updates you should automatically download and install a patch.  If you go look at your add/remove programs you should see the patch installed.
(In reply to comment #234)
> As for updates on my part, getting patching working took a lot more effort than
> I expected (mostly because WiX subscribes to the "code is the documentation"
> philosophy when it comes to patching).  I've been able to successfully generate
> a MSP patch (though not a binary patch, that crashed the toolchain but I'm not
> sure if that was an input problem or a bug in WiX yet).

This appears to be a bug in WiX.  The transform generating tool (torch) recognizes DLLs that have the same version but different timestamps as different files (though it can tell that two EXEs with different timestamps are the same).  The patching utility (pyro) then chokes because there is no actual difference between the files.
Depends on: 543390
Depends on: 543392
Depends on: 543393
I've filed bugs to move some tangential work out of here, stuff relating to the UI and end-users mostly to focus on producing a working MSI with updates in this bug.
Blocks: 545294
This bug is waiting on:

1) Implementing shortcuts
2) Implementing the necessary registry keys for shell integration
3) Writing tools/update-packaging scripts for MSIs.
4) Write patch template for Firefox. (The wxs file)

After reading MSDN some more we really don't need to worry about managing upgrade codes.  I think we can give every Firefox (Thunderbird, Seamonkey, etc) the same upgrade code because we manage the update side ourselves.  Upgrade codes also don't have to be unique per locale.

As for product codes, we want a differing product code for everything we want to be easily installable side by side (eventually we'll want everything to be installable both side by side and multiple times, but that's for Bug 543392)
That means we need product codes for:
- Trunk Nightlies (1)
- Branch Nightlies (1 per branch)
- Branch Milestones (1 per branch)
- Branch Stable Releases (1 per branch)
These also all need to be unique across locales to allow installing say the trunk en-US and trunk zn-TW side by side.

I think the best way to do this is with a python script that generates a UUID based on a string like "@MOZ_APP_NAME@/@MOZILLA_VERSION@/@AB_CD@".  That guarantees us uniqueness across all the things I listed above and doesn't require us to manually track (1+3*n supported branches)*m supported locales GUIDs.

Comment 241

7 years ago
(In reply to comment #240)
> These also all need to be unique across locales to allow installing say the
> trunk en-US and trunk zn-TW side by side.

IMO that's an overkill.
(In reply to comment #241)
> (In reply to comment #240)
> > These also all need to be unique across locales to allow installing say the
> > trunk en-US and trunk zn-TW side by side.
> 
> IMO that's an overkill.

Product codes are required to vary for other reasons too (http://msdn.microsoft.com/en-us/library/aa370854%28VS.85%29.aspx)

They also need to vary based on the target architecture x86 and x64 must have differing product codes.
Depends on: 547225
(In reply to comment #240)
> This bug is waiting on:
> 
> 1) Implementing shortcuts
> 2) Implementing the necessary registry keys for shell integration
These two are being handled in the patch in Bug 547225.  Once that bug is fixed the necessary code on the MSI side is 3 or 4 lines of XML.

> 3) Writing tools/update-packaging scripts for MSIs.
Still working on.  This is tricky because of the various idiosyncrasies of MSI patching.

> 4) Write patch template for Firefox. (The wxs file)
This is done.

I think this will be ready for initial review by the end of next week.
(In reply to comment #243)
> I think this will be ready for initial review by the end of next week.

That's not going to happen, Bug 547225 turned out to be more involved than I thought.

(To myself so I remember this) Also, after thinking about this some more, I'm not sure that using the Heat tool from the WiX toolset is the best idea.  The main reason is the hackery that I currently have implemented to get the directory tree to work properly (which could break if two directories have the same name and one contains no l10n files and the other contains only l10n files), though there are some other issues related to features and patching.  It should be fairly straightforward to rewrite the guts of Heat in Python and have it process the package-manifest and removed-files files to generate the proper WiX XML for the compiler.  This has the upside of removing files through patching much easier.

That said, I will still probably have to patch WiX's patch utility since it crashes whenever you feed it two DLLs that are identical except for version (e.g. nightlies)
Nightlies will always generate different dll's even if the code doesn't change.
Current up to date summary of the planning for this is at https://wiki.mozilla.org/MSI
Created attachment 440037 [details] [diff] [review]
Part 1: Clean up the cruft from last time.

Gerv removed most of these files in Bug 324118, but there is some cruft remaining.  Let's clean that out before we get started.
Attachment #278253 - Attachment is obsolete: true
Attachment #313598 - Attachment is obsolete: true
Attachment #352091 - Attachment is obsolete: true
Attachment #420438 - Attachment is obsolete: true
Attachment #420705 - Attachment is obsolete: true
Attachment #420740 - Attachment is obsolete: true
Attachment #440037 - Flags: review?(jmathies)
Created attachment 440041 [details] [diff] [review]
Part 2: Provide branding info in a WiX friendly fashion

We need to provide the branding information in a format that WiX can accept.  Depending on our distaste for duplication, we could store the branding info in the makefiles and preprocess template .nsi and .wxi files to avoid duplicating the info.
Attachment #440041 - Flags: review?(robert.bugzilla)
Attachment #440041 - Attachment is obsolete: true
Attachment #440041 - Flags: review?(robert.bugzilla)
Created attachment 440045 [details] [diff] [review]
Part 2: Provide branding info in a WiX friendly format

Let's try this one again.
Attachment #440045 - Flags: review?(robert.bugzilla)
Created attachment 440050 [details] [diff] [review]
Part 3: Capture the self-registration information from DLLs

We need a way to capture the self registration information from a DLL.  We can't hardcode this information in the WiX files because the self registration registry entries need to be part of the same component as the DLL they belong to, and the WiX markup for the actual files being installed is going to be generated at build time.  This small tool lets us capture the self registration information and examine it with a script to create the WiX markup later.  This is necessary for proper installation of AccessibleMarshall.dll
Attachment #440050 - Flags: review?(jmathies)
Attachment #440045 - Attachment is obsolete: true
Attachment #440045 - Flags: review?(robert.bugzilla)

Updated

7 years ago
Attachment #440037 - Flags: review?(jmathies) → review+
nits mostly - 

> +  unsigned long l;

Lets use something like dwRes here.

> +  SHDeleteKey(HKEY_CURRENT_USER, L"Software\\SelfRegCap");

Maybe "Software\\Mozilla\\SelfRegCap" so we get the blame if it's not cleaned
up? 

> +  RegOverridePredefKey(HKEY_CLASSES_ROOT, diversionKey);

Shouldn;t we check for failure here, otherwise we might register the dll proper
farther down.

> +    (*p)();

Do we care about the result?
(In reply to comment #251)
> nits mostly - 
> 
> > +  unsigned long l;
> 
> Lets use something like dwRes here.
> 
> > +  SHDeleteKey(HKEY_CURRENT_USER, L"Software\\SelfRegCap");
> 
> Maybe "Software\\Mozilla\\SelfRegCap" so we get the blame if it's not cleaned
> up? 
> 
> > +  RegOverridePredefKey(HKEY_CLASSES_ROOT, diversionKey);
> 
> Shouldn;t we check for failure here, otherwise we might register the dll proper
> farther down.
> 
> > +    (*p)();
> 
> Do we care about the result?

All good points, will fix.
(In reply to comment #252)
> > > +    (*p)();
> > 
> > Do we care about the result?
> 
> All good points, will fix.

I was thinking about this while grabbing some lunch. Seems like if the test reg fails, the install should fail because the dll likely isn't going to register. Sort of an early dependency test before we actually do the main registration.
(In reply to comment #253)
> (In reply to comment #252)
> > > > +    (*p)();
> > > 
> > > Do we care about the result?
> > 
> > All good points, will fix.
> 
> I was thinking about this while grabbing some lunch. Seems like if the test reg
> fails, the install should fail because the dll likely isn't going to register.
> Sort of an early dependency test before we actually do the main registration.

I agree, just want to point out that this is happening at build time, not at install time.  If the DLL fails to self-register we should just abort building the installer.  During install we're never going to actually self-register the DLL, we're going to let the MSI engine handle the registry entries that we captured (this is required for repair functionality and making the MSI component model work).
Attachment #440050 - Attachment is obsolete: true
Attachment #440050 - Flags: review?(jmathies)
(In reply to comment #254)
> I agree, just want to point out that this is happening at build time, not at
> install time.  If the DLL fails to self-register we should just abort building
> the installer.  

So over time we could end up with a very large number of dll's registered on the build machines ? If so, could we take some steps to unregister each dll after a successful registration in order to keep the registry trimmed down ?
(In reply to comment #255)
> (In reply to comment #254)
> > I agree, just want to point out that this is happening at build time, not at
> > install time.  If the DLL fails to self-register we should just abort building
> > the installer.  
> 
> So over time we could end up with a very large number of dll's registered on
> the build machines ? If so, could we take some steps to unregister each dll
> after a successful registration in order to keep the registry trimmed down ?

Yes.  The general plan is to do:

"selfregcap.exe foo.dll"
examine the diverted registry key and generate the appropriate WiX markup if any
"selfregcap.exe" (which will delete the diverted registry key and clear out all of the information)

Additionally I'm marking this registry key as volatile so it should not persist across reboots.
Created attachment 440465 [details] [diff] [review]
Part 2: Provide branding information to WiX

Third time is the charm.  The main point of interest here is whether we want to duplicate the branding information or if we should preprocess .nsi and .wxi templates with branding information stored in the makefile or something similar.
Attachment #440465 - Flags: review?(robert.bugzilla)
Created attachment 440466 [details] [diff] [review]
Part 3: Capture the self-registration information from DLLs V1.1

Review comments addressed.
Attachment #440466 - Flags: review?(jmathies)
Created attachment 440469 [details] [diff] [review]
Part 2.1: Fix comments in branding information

Trivial fix to comments in branding information which have an incorrect location.
Attachment #440469 - Flags: review?(robert.bugzilla)
Comment on attachment 440466 [details] [diff] [review]
Part 3: Capture the self-registration information from DLLs V1.1

if (S_OK != dwRes) {

I believe there are other return values we can get here that indicate success. MSDN says S_OK is the expected return value but if we have access to it, we might want to use the SUCCEEDED macro.
Attachment #440466 - Flags: review?(jmathies) → review+
(In reply to comment #260)
> (From update of attachment 440466 [details] [diff] [review])
> if (S_OK != dwRes) {
> 
> I believe there are other return values we can get here that indicate success.
> MSDN says S_OK is the expected return value but if we have access to it, we
> might want to use the SUCCEEDED macro.

Good point.  I've fixed this in my queue.
Comment on attachment 440466 [details] [diff] [review]
Part 3: Capture the self-registration information from DLLs V1.1

Not sure if the localization process will require localizers to also run this but if they do need to then the binary for this will likely need to be added to mozilla-build.

Comment 263

7 years ago
There's another drastic packaging change, omnijar in bug 552121. Not sure how these two interact.
(In reply to comment #263)
> There's another drastic packaging change, omnijar in bug 552121. Not sure how
> these two interact.

Can't really tell if they interact or not based on what's been written in the bug, but I will watch it.  Thanks for the heads up!

(In reply to comment #262)
> (From update of attachment 440466 [details] [diff] [review])
> Not sure if the localization process will require localizers to also run this
> but if they do need to then the binary for this will likely need to be added to
> mozilla-build.

This is being run only for the build of the language-neutral portion, so that won't be necessary.
Created attachment 440729 [details] [diff] [review]
Part 4: Process package-manifest into WiX markup.

Now things start to get interesting.  Here we process the package-manifest file into WiX markup.  Each [foo] directive becomes a ComponentGroup element and each file becomes a File element.  We keep the l10n files separate so that we can handle localization of the installer later.  I'm assuming here that the only localized group is going to be the AB_CD group.  That appears to be true for all of the toolkit apps.  We also may need to modify this eventually to handle optional groups for the other apps.

The output from this is two separate WiX files, "pyheat <arguments> base" produces one containing a fragment which contains all of the markup to handle the non-localized components (one component for each file) and "pyheat <arguments> l10n" produces the other containing all of the markup to handle localized components (again, one component for each file).
Attachment #440729 - Flags: review?(jmathies)
Created attachment 440730 [details] [diff] [review]
Part 5: Connect Parts 3 and 4

This should be pretty straightforward, we call the helper executable we built in part 3, figure out what to do with the output, and then call the helper again to clean up the registry entries.
Attachment #440730 - Flags: review?(jmathies)
Created attachment 440733 [details] [diff] [review]
Part 6: Handle directories and files removed in point releases 

This patch does two things.  First it modifies pyheat to create a WiX file with the directory layout, which we'll need when we build the MSI.  This is done by calling "pyheat <arguments> dir".  We could fold this into the general non-localized components file if we wanted to; I kept them separate primarily for ease of debugging.

The second is more interesting.  One of the many quirks of the MSI engine is that minor upgrades don't allow you to remove files easily.  For upgrade scenarios you get to choose between:

1) A major upgrade which removed all installed files and recopies all newer versions.  This requires shipping a complete MSI.
2) A minor upgrade which changes only the files it needs to.  This allows us to ship an MSP that only contains the binary diffs of what we need.

We'll want to do 2, obviously.  Since for some brain-dead reason the component structure must be only grow across minor upgrades (that is, we cannot remove components, you actually can add components just fine) this patch causes "pyheat <arguments> rm" to generate a WiX file that creates dummy component entries with a false condition (so that they will be removed in the patch).  This is hackish but it's the canonical way to handle this[0].  This requires us to maintain a separate list of files that we've removed from an MSI in a point release.  This "msi-removed-files" (not part of this patch since it'll live in /<application>(/installer/windows/msi), not /toolkit) will be empty on trunk and then if we find we need to remove a file after shipping off that branch we can add the files there. (we could also find a way to annotate removed-files.in with what got removed in what release, but that seems harder).

I'm not sure that we'll need to remove files on point releases but it seems better to design for the possibility rather than needing to figure out what to do when we decide that we want to do that (especially because not handling this now requires EVERYONE to be aware that removing files in point releases is not safe).

Brain-dead design ftw.

[0] http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx
Attachment #440733 - Flags: review?(jmathies)
Created attachment 440734 [details] [diff] [review]
Part 7: Generate product codes at build time

Tiny python script to generate a product code from its argument.  In the makefile we're going to feed this script the string

"www.mozilla.org/msi-namespace/$(MOZ_APP_NAME)/$(MOZILLA_VERSION)/$(TARGET_CPU)/$(AB_CD)"

So product codes will vary by app, version, architecture, and locale.  Variation by architecture and locale is required, variation by app is good too (don't want Thunderbird overwriting Firefox) and variation by version is a prerequisite to installing multiple versions side by side.
Attachment #440734 - Flags: review?(robert.bugzilla)
Created attachment 440735 [details] [diff] [review]
Part 8: Reflect build system variables into WiX

These are the build system variables we'll need in the WiX.
Attachment #440735 - Flags: review?(jmathies)
That last one will make a bit more sense after I post the makefile patch, but I'm out of patch splitting time this morning so that will happen tonight.
Attachment #440735 - Attachment is obsolete: true
Attachment #440735 - Flags: review?(jmathies)
Created attachment 441140 [details] [diff] [review]
Part 8: Reflect build system variables into WiX

Cleaned up version
Attachment #441140 - Flags: review?(jmathies)
Created attachment 441141 [details] [diff] [review]
Part 9: Provide app-agnostic MSI building capability

This is the toolkit portion of the MSI makefile.  The app specific makefile will include this and define the variables MOZ_MSI_L10N_FILES and MOZ_MSI_NOL10N_FILES for the files that should be included in the localized and non-localized parts of the build process.

The $(MOZ_APP_NAME)_base.wixlib file the is the language neutral intermediate file.  All of the language neutral files will be linked into this library.  Localized builds will then be built by combining this file with the localized files.  Building the wixlib is ifdefed so that we don't try to build it again during the l10n packaging stage.
Attachment #441141 - Flags: review?(jmathies)
Created attachment 441220 [details] [diff] [review]
Part 10: Build a (very) basic en-US Firefox MSI

This patch hooks up Firefox to the Toolkit foundations we've laid so far and produces a working MSI.  What we have at this point is hardcoded en-US and is essentially a glorified ZIP installer :-) (no shell/registry integration, no shortcuts, etc.)
Attachment #441220 - Flags: review?(jmathies)
Created attachment 441221 [details] [diff] [review]
Part 10: Build a (very) basic en-US Firefox MSI

I really wish there were something that stops me from attaching things if I forget to qrefresh.
Attachment #441221 - Flags: review?(jmathies)
Attachment #441220 - Attachment is obsolete: true
Attachment #441220 - Flags: review?(jmathies)
Comment on attachment 440465 [details] [diff] [review]
Part 2: Provide branding information to WiX

I don't think we want to bother with implementing SurveyURL for uninstall presently unless there is a way to open an url unelevated from the uninstaller when it is launched from Programs and Features.

Also, I have no problem with changing any of the names from what was used in NSIS if the new names are clearer.

I'm fine with this and I'm mainly minusing to get answers to the above
Attachment #440465 - Flags: review?(robert.bugzilla) → review-
(In reply to comment #275)
> (From update of attachment 440465 [details] [diff] [review])
> I don't think we want to bother with implementing SurveyURL for uninstall
> presently unless there is a way to open an url unelevated from the uninstaller
> when it is launched from Programs and Features.

We can do that.  We'll condition a custom action to run on uninstall that ShellExecutes the URL (custom actions can run at low privilege).

When we implement this though we'll have to make it configurable via a property or something so that it doesn't run in an institutional scenario.

> Also, I have no problem with changing any of the names from what was used in
> NSIS if the new names are clearer.

I think these names are fine.  IIRC the relevant names correspond exactly to the ARP registry keys and I don't see anything wrong with BrandFullNameInternal and SurveyURL.  If you have suggestions though, I can change them.
(In reply to comment #276)
> (In reply to comment #275)
> > (From update of attachment 440465 [details] [diff] [review] [details])
> > I don't think we want to bother with implementing SurveyURL for uninstall
> > presently unless there is a way to open an url unelevated from the uninstaller
> > when it is launched from Programs and Features.
> 
> We can do that.  We'll condition a custom action to run on uninstall that
> ShellExecutes the URL (custom actions can run at low privilege).
> 
> When we implement this though we'll have to make it configurable via a property
> or something so that it doesn't run in an institutional scenario.
It would be optional on the last page of the uninstall / not available for silent uninstalls and off by default so I don't think we need to do anything for admin scenarios / corp environments. Keep in mind that shellexecute against a url won't work if we were the default browser unless we set another browser as default.

> 
> > Also, I have no problem with changing any of the names from what was used in
> > NSIS if the new names are clearer.
> 
> I think these names are fine.  IIRC the relevant names correspond exactly to
> the ARP registry keys and I don't see anything wrong with BrandFullNameInternal
> and SurveyURL.  If you have suggestions though, I can change them.
Sounds good.
Attachment #440465 - Flags: review- → review+
Attachment #440469 - Flags: review?(robert.bugzilla) → review+
Comment on attachment 441140 [details] [diff] [review]
Part 8: Reflect build system variables into WiX

Can a newline be added to this file? If not that's fine.

btw: I don't know if jimm is fluent in python and I'm not all that knowledgeable in python... might want to ask around on irc for someone to review the python patches.
Comment on attachment 440734 [details] [diff] [review]
Part 7: Generate product codes at build time

I'm a little concerned with creating a uuid each time... we have talked about it before but can you prove some info that might help assuage my concerns?
(In reply to comment #278)
> (From update of attachment 441140 [details] [diff] [review])
> Can a newline be added to this file? If not that's fine.

Yes, it could be.

> btw: I don't know if jimm is fluent in python and I'm not all that
> knowledgeable in python... might want to ask around on irc for someone to
> review the python patches.

OK.

(In reply to comment #279)
> (From update of attachment 440734 [details] [diff] [review])
> I'm a little concerned with creating a uuid each time... we have talked about
> it before but can you prove some info that might help assuage my concerns?

Sure. We're creating a UUID based on "www.mozilla.org/msi-namespace/$(MOZ_APP_NAME)/$(MOZILLA_VERSION)/$(TARGET_CPU)/$(AB_CD)".  Version 5 UUIDs ( http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_5_.28SHA-1_hash.29 ) are formed by taking a SHA-1 hash of the input string and combining that with some other stuff specified in the RFC.  As long as the input string remains the same the UUID produced will remain the same (on all computers, everywhere.  Only version 1 UUIDs depend on MAC addresses).

Because of the string chosen our product codes will vary based on the appname, app version, CPU arch, and locale.  CPU arch (really whether it's 32 or 64 bit, but this looks like how we get at it elsewhere) and locale are required by Windows Installer.  The product code must also be different for any versions that should be installable side by side (there's more required elsewhere to make that possible though). http://msdn.microsoft.com/en-us/library/aa370854%28VS.85%29.aspx
Feel free to throw the Python bits into my review queue.
Attachment #440729 - Flags: review?(jmathies) → review?(ted.mielczarek)
Attachment #440730 - Flags: review?(jmathies) → review?(ted.mielczarek)
Attachment #440733 - Flags: review?(jmathies) → review?(ted.mielczarek)
(Reporter)

Comment 282

7 years ago
What is the end-game here?  Is it that once this bug is fixed, Firefox's installer will start being MSI?  Or is it just that Mozilla.org will have the ability to deploy as MSI? 

Is this bug a meta-bug and a code enhancement at the same time, meaning that even once the code lands on trunk this bug will remain open until the others are fixed?

Don't get me wrong, I'm cheering to see it this close already.  I just want a bit of clarity.
My goal is that when this bug is closed the build system will be able to produce an MSI packaged Firefox that is localized properly, capable of receiving MSP updates, and capable of handling all applicable shell/OS integration.  The package produced will be suitable for use in a corporate/institutional deployment scenario, though not necessarily for end-users.

In particular, the explicit non-goals for this bug are to:
1) Provide a working user interface in the installer.  All of the settings will be customized on the command line for the time being.  Bug 543390 will cover this.
2) Use 7 zip compression.  Bug 543393 will cover this.
3) Be able to install multiple instances side by side.  This is hard.  Bug 543392 will cover this.

Replacing the NSIS installer with an MSI solution will still be relatively far away when this bug is closed.

Comment 284

7 years ago
Which of the 10 patches does the l10n piece right now? Might make sense for me to have a look at that one.
Attachment #441141 - Attachment is obsolete: true
Attachment #441141 - Flags: review?(jmathies)
Created attachment 442920 [details] [diff] [review]
Part 9: Provide app agnostic MSI building capability V1.1
Attachment #442920 - Flags: review?(jmathies)
Depends on: 563186
Created attachment 442946 [details] [diff] [review]
Part 11: Support l10n packaging

This patch does the necessary magic to support a non-en-US MSI package.  The patch in Bug 563186 needs to be applied between Part 10 and Part 11 to successfully build an l10nized MSI.

Notes:
I'm setting the MSI's language to 0 (language neutral).  The language property is important only for selecting UI strings for strings not stored in the MSI database.  For the moment that means that the progress dialog presented when installing the MSI will be in English regardless of the locale.

I'm stealing the NSIS helper.exe for the moment.  That will change in a future Part.

Axel: this is the piece you are looking for.
Attachment #442946 - Flags: review?(jmathies)
Attachment #442946 - Flags: feedback?(l10n)
I think it's reasonable to have what I described in Comment 283 for Firefox 3.7.
Target Milestone: Future → Firefox 3.7
(Reporter)

Comment 288

7 years ago
If the old installer is NSIS and the new one is MSI, do we need a bug for swapping the installers during an upgrade?
That is quite a few steps away from where we are now and I'd prefer to wait until we are farther along before filing more bugs unless the person doing the work (e.g. Kyle) sees a need to file / work on the additional bug(s) at this time.
Created attachment 442956 [details] [diff] [review]
Part 12: Write the product code to disk for later use

We'll want to store the product code on disk so that we can use it later (e.g. so that the app updater, shell integration, etc can make sure they're dealing with the right installation)
Attachment #442956 - Flags: review?(jmathies)
Created attachment 442957 [details] [diff] [review]
Part 13: Look pretty in Add/Remove Programs

Set the standard MSI ARP properties.  The MSI engine will create the right registry keys from these properties.  See http://msdn.microsoft.com/en-us/library/aa368032%28VS.85%29.aspx
Attachment #442957 - Flags: review?(jmathies)
Created attachment 442958 [details] [diff] [review]
Part 14: Tell Windows we know what we're doing with UAC.

We're going to interact properly and we don't want Windows guessing what to do on our behalf.

http://msdn.microsoft.com/en-us/library/bb73631