Closed Bug 69691 Opened 24 years ago Closed 23 years ago

Installer should *not* leave the program folder open

Categories

(SeaMonkey :: Installer, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: bugzilla, Assigned: curt)

Details

Attachments

(2 files)

When doing the installation the installer leaves the "program folder" that 
you choose (normally mozilla) open.
This is not standard behavior on windows installer and is kind of wierd since 
the installer lauches mozilla at the end of the installation so there's no need 
to show the mozilla folder to the users.
It's standard behavior on a lot of Windows installers I've seen. In fact, I 
think it would be preferable to open the folder rather than to launch Mozilla; 
if you're installing Mozilla on a bunch of PCs, you don't want to go around 
exiting Mozilla on all of them once you're done.
If I install mozilla on multiple pc's i'll use a script (do we have a command 
line parameter for silent installs?) or something, I don't want the folder to 
open up either -- especially because windows will remember that it opened the 
folder.

If an installer leaves a folder open, it's the start menu folder, not the 
installation folder.
ups... wrong subject...:)
Summary: Installer should leave the program folder open → Installer should *not* leave the program folder open
On windows there are lots of options, feed the "-h" option to it for a list. 
You can do a "silent" install, disable the launching at the end, disable the 
opening of the program group, etc.
still think it should be the other way around. Default should be not to open the 
program folder. If the user then want to do it, he can do it via a "-opf" option
oh. also, please don't open an explorer window if explorer isn't running on the 
current deskbar.  especially if it's the shell.

Doing so results in a really ugly dialog box complaining about invalid 
parameters. but it does _not_ result in the folder being opened.

Steps to reproduce: run cmd.exe
click start>shutdown. hold ctrl-alt-**** click cancel/no.
enter the path to the installer, and go through the normal process.

fwiw this isn't actually the way i produced the behavior, i was using 
switcher.exe (requires NT, i use w2k) which meant that only some deskspaces had 
explorer running, and not the one where i was guinea pigging the 093 stub 
installer.

If you wnat a seperate bug for this i can file one.
It does not open the Program folder of mozilla, but the start menu with the 3 
mozilla icons. It is not many installers doing so and it annoys me every time.

Mozilla is launched anyway (which is good to do all the initial registration at 
install time), presenting the icons is therefore somewhat unneccesary.
This should be an easy fix via the config.it file.  However, this is more like a
feature remove request.  I'll let Curt decide.  Perhaps we need UE input?
Assignee: ssu → curt
Gregg, could I get your on this bug?
Just to be perfectly clear, "input" is what I'd like to get.  Money is okay, too.
I just wanted to note that, though this was common behaviour in the days of
Windows 3.1 (with 'Program menu groups'), there is no real reason for it today
and the vast majority of modern installers do not open up start menu folders. It
shouldn't display at all, never mind staying open.

Users may likely not even expect to see bits of the start menu represented as a
folder in this way. It's not exactly the same way they will start the program in
future.

Basically, it's a very small thing and it only bugs me because I install the
program regularly :) but it does give a bad first impression, so would be nice
if it could be tweaked.
I'll go with s.marshall's input.  It makes sense to me.  And who wants to buck
"the vast majority of modern installers"!  Seriously, all I ever do is close
that folder and never open it again.  I can't think why anyone else would do
differently.
Status: NEW → ASSIGNED
I think all you have to do is change the Show Folder= setting from SHOW to HIDE
in the installer config file.
oui
If your going to make it that easy for me I guess I should just fix it.  Here
is the patch.
Attached patch ditto for nsSplinter Review
Target Milestone: --- → mozilla0.9.7
The patches are checked in.  (Gregg, I sure hope we wanted this for NS, too,
cause I sure enough checked it in for both.)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
BTW, I got r= and sr= verbally from Sean and Dan.
Yes, that is fine.
sure is fixed! hurray!
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: