Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521 Firefox/1.0+ To make scripted installations easier, there needs to exist an installer switch that would allow the user to keep the portion of the installer that asks about creating shortcuts from appearing as well as prevent their creation at all. I was able to (for some freaky reason) get this effect with (I believe) the -ispf switch, but that is apparently not the correct behavior for that switch per bug 290704. Adding this enhancement would make it easier for people who have multiple versions of FF installed for testing purposes and don't want to worry about it creating unused and ultimately annoying shortcuts all over the place.
Morphing this somewhat: The installer should have a flag that defines a subset of shortcut locations, so that sysadmins can selectively create shortcuts. Something like --as=N, where N is a bitmask of possible values. In the current windows installer we support Desktop, Quick Launch, and Start Menu locations (defaulting to all three). Desktop 1 Quick Launch 2 Start Menu 4 Thus, --as=0 would create no shortcuts, and --as=6 would create Quick Launch and Start Menu shortcuts. Given that the only people who really care about this would be sysadmins/testers, I think we both need and want the flexibility, even if it needs to be more documented.
Assignee: nobody → mconnor
OS: Windows XP → All
Hardware: PC → All
Summary: Executable installer needs a flag to prevent creation of desktop, quicklaunch, and start menu shortcuts/folders. → Add install switch to specify which shortcuts to create.
Target Milestone: --- → Firefox1.1
(In reply to comment #1) > Morphing this somewhat: > > The installer should have a flag that defines a subset of shortcut locations, so > that sysadmins can selectively create shortcuts. > > Something like --as=N, where N is a bitmask of possible values. In the current > windows installer we support Desktop, Quick Launch, and Start Menu locations > (defaulting to all three). > > Desktop 1 > Quick Launch 2 > Start Menu 4 > > Thus, --as=0 would create no shortcuts, and --as=6 would create Quick Launch and > Start Menu shortcuts. Given that the only people who really care about this > would be sysadmins/testers, I think we both need and want the flexibility, even > if it needs to be more documented. Wow, that is a much better solution than what I had planned. I like that idea, and it would make sciptability improve dramatically, IMO. The only issue I had was with the switch name you chose. --as isn't very descriptive of what it does, unless it is some acronym I am not familiar with. I can't think of anything at the moment that would be descriptive and short, unfortunately.
OS: All → Windows XP
Hardware: All → PC
Target Milestone: Firefox1.1 → ---
For some reason (must have been something I hit accidentally) this got retargeted. Fixing it back to where mconnor put it.
Target Milestone: --- → Firefox1.1
I realize this already has a target milestone for 1.1, but I believe it should block the release of 1.1 as well. This is extremely important to people who QA on Windows, or at least those who know about all the nifty things you can do with the installer in scripts.
Patches welcome, but we're not going to block on this.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(In reply to comment #5) > Patches welcome, but we're not going to block on this. I understand the logic, but I am not quite sure what portion of the source should be patched. I would be more than willing to try to write a patch for this, unfortunately, I am not familiar enough with the source to know exactly what all needs to be changed.
This is something I am planning on handling with NSIS.
Assignee: mconnor → robert.bugzilla
Target Milestone: Firefox1.5 → Firefox 2 beta1
pushing out non-critical-path bugs to b2
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Created attachment 229577 [details] Config file To support this I am adding an optional command line argument for specifying a configuration ini file for specifying shortcut creation, start menu folder name, install dir name or full path, and whether to close the app if running as follows: ; The name of the directory where the application will be installed in the ; system's program files directory. The directory must not exist or if it exists ; it must be a directory and not a file. If this value is specified then ; InstallDirectoryPath will be ignored. ; InstallDirectoryName=Mozilla Firefox ; The full path to the directory to install the application. The directory must ; not exist or if it exists it must be a directory and not a file. ; InstallDirectoryPath=c:\firefox\ ; Close the application when installing into a location where the application ; is already installed and the file is in use (e.g. it is already running). If ; this value is not specified the installer will not exit without installing ; the application and will return an error code of 1. ; CloseApplication=1 ; By default all of the following shortcuts are created. To prevent the ; creation of a shortcut specify false for the shortcut you don't want created. ; ; Create a shortcut for the application in the current user's QuickLaunch ; directory. ; QuickLaunchShortcut=false ; ; Create a shortcut for the application on the desktop. This will create the ; shortcut in the All Users Desktop directory and if that fails this will ; attempt to create the shortcuts in the current user's Start Menu directory. ; DesktopShortcut=false ; ; Create shortcuts for the application in the Start Menu. This will create the ; shortcuts in the All Users Start Menu directory and if that fails this will ; attempt to create the shortcuts in the current user's Start Menu directory. ; StartMenuShortcuts=false ; The directory name to use for the StartMenu folder. ; note: if StartMenuShortcuts=false is specified then this will be ignored. ; StartMenuDirectoryName=Mozilla Firefox
Status: NEW → ASSIGNED
Whiteboard: 2d → 2d [deployment issue]
The patch in bug 344490 provides the ability to specify which shortcuts to create via a config file. I think this is more than adequate for fixing this bug since it supports scripted installations including several additional parameters for controlling how the app is installed.
Whiteboard: 2d [deployment issue] → [deployment issue]
No longer depends on: 344490
Fixed on trunk and MOZILLA_1_8_BRANCH by the checkin of bug 344490 - see bug 344490 for details.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.