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.

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

See also http://www.installsite.org/pages/en/msi/authoring.htm

We should ask apache.org how they do it

IRC discussion: http://www.pseudorandom.org/irclog/mozilla/%23mozilla/%23mozilla.2004-01/%23mozilla.2004-01-15.log

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

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.

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.

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.

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

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.

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

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.

not going to block the release for this, but its something I really want to see as an option (how is another issue entirely)

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

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.

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

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

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.

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.

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

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

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.

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

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.

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

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.

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

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

Yes, you can attach zips.

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.

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

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.

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

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.

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.

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.

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.

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.

Tests for my MSI's are being tracked here. http://forums.mozillazine.org/viewtopic.php?t=138033

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?

(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

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

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

yuu

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

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

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.

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

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.

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

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

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.

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

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

for an unoffical MSI packaging for 1.0 see http://forums.mozillazine.org/viewtopic.php?t=138033 These were built using MakeMSI

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.

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.

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

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

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

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.

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)

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?

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

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.

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?

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.

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.

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?

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.

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

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

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

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.

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

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

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?

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.

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

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

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

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?

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

(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

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

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.

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

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.

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.

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

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

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.

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.

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

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?

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

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

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.

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.

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.

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

Re: shadowchaser@transfur.com Hear, hear! [clap clap clap]

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.

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

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.

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.

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!

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.

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

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

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.

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

(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

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

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.

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.

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

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.

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?

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.

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

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.

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

This will not block the final release of Firefox 3.

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

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

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.

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 .

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?

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?

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

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

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

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

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

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

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

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.

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

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.

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.

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

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.

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.

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.

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

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

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

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

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

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

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.

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

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

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

(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

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