Closed Bug 233625 Opened 21 years ago Closed 20 years ago

Uninstalling deleted non-Firefox folders (after installing to C:\Program Files\)

Categories

(Firefox :: Installer, defect, P2)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox1.0beta

People

(Reporter: tpassin, Assigned: dveditz)

References

(
URL
)

Details

(Keywords: dataloss, fixed-aviary1.0.1, helpwanted)

Attachments

(2 files)

Patch to check if a directory is empty
1.74 KB, patch
Details | Diff | Splinter Review
Don't delete things we didn't install
826 bytes, patch
mconnor
: review+
asa
: approval-aviary1.0.1+
Details | Diff | Splinter Review 
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.6 StumbleUpon/1.73

The new Firefox Windows installer - for a custom install location - put the
Firefox files into the top level of my d:\Program Files directory.  I did not
want this, so I uninstalled it from the Windows Control Panel Uninstall applet.
 It did not uninstall so I logged in as adminstrator and then ran the uninstall.

THe unintall took a long time with lots of disk activity.  At the end of it,
about 2/3 of the folders in Program Files had been deleted.  I lost dozens of
applications, many of them requiring serial numbers to reinstall, and all the
associated configuration, etc.  Included in the carnage were two other Mozilla
installations and my Thunderbird 0.4 installation, and Winzip which of course I
needed to unzip replacements.

This is DANGEROUS.

Reproducible: Didn't try
Steps to Reproduce:
1.
2.
3.



Expected Results:  
1) The installer should have made clear where the files were going to be put.  I
had navigated to d:\Program Files, then typed in Mozilla Firefox 0.8, but the
last step of the path was not reflected in the edit box.  However, some
installers add the last step anyway.  So the destination was not clear, and the
installer had not folled my commands.

2) The uninstaller should NEVER touch ANY files it has not installed.
Summary: WARNING - Firefox 0.8 Windows Installer Deleted Non-Mozilla Folders During Uninstall → Uninstalling deleted non-Firefox folders (after installing to C:\Program Files\)
Could be related or dup of bug 228672.
The installer must have asked you if you wanted to delete all the files under
c:\program files\, right?

See bug 228672, comment 67


*** This bug has been marked as a duplicate of 228672 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
I just read throug Bug 228672, and I do not believe that this bug is a
duplicate.  Bug 228672 refers to the installer, while this bug refers to the
uninstaller.

In fact, although Bug 228672 has been taken care of, this bug with the
uninstaller still remains.  A user as mozillazine just reported loss of data
using the unistaller: 
http://forums.mozillazine.org/viewtopic.php?t=64871&sid=2d93836acbfea243769078b48c3eff90
I just tested this bug on the latest nightly installer.

I do get a dialog asking if I want to delete the folder.  If I click yes, it
does delete everything in the folder as well as the folder itself (which
included non-firefoxe files).

I'm not sure if the dialog is considered enough, however considering that a user
lost their files over this, perhaps a new solution should be considered?
I am the user from the post, that had the files deleted. I cannot overstate the severity of this problem. This is not a minor inconvience. This is CARNAGE!!! Uninstalling a browser and ending up wiping out almost your entire hard drive.

I am an long time user of phoenix used to deleting the old folder and unzipping directly into the program folder. This is why I made the mistake of installing directly into programs file. We need the old zipped version back.

Uninstallers should NEVER_uninstall files that not installed by application. 
Bug 228672 is marked as fixed, but this bug isn't, so this bug isn't a dup of
bug 228672.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Bug 234741 is fixed for mozilla suite. Related?
See http://forums.mozillazine.org/viewtopic.php?t=74908

blocking 1.0?
Flags: blocking1.0?
I think blocking 0.9 would be more appropriate.

Did this issue of firefox deleting files not installed by firefox during uninstall get resolved?
Keyword -> dataloss, pp?

Just as a note, this could mess up a computer pretty badly.  I wish there was
some way to indicate the severity of this bug (since a Severity of "Critical" or
a "dataloss" keyword just doesn't represent how severe this issue can be).
Keywords: dataloss
Flags: blocking0.9?
So in a situation where we uninstall, but something else is in the directory,
should we just ignore that?

The biggest problem with this bug is that its only a problem if you 

1) do a custom install
2) install somewhere stupid like into C:\program files\
3) do an uninstall, and either blindly or ignorantly agree to explicitly delete
all filse in the named folder.  Its not like it does it automatically.

maybe we should change the installer to automatically create a Firefox
directory, and default to C:\Program Files\Mozilla, and have a blurb that the
installer will automatically create a folder "firefox" in the folder specified?
 it would save a lot of silly people making bad assumptions from nuking their drives
All an uninstaller should do is delete what was created by the installer.  The
only exception is where it comes to deleting a directory that it was expecting
to be empty but wasn't, and all it should do then is notify the user what
happened (without deleting anything it possibly shouldn't).

"All an uninstaller should do..."

That's safer, yes. However, some people will complain if the uninstallation
leaves behind the folder because it has one file in it that wasn't created by
the installer. I've seen complaints from people that the uninstallation didn't
remove the profile.

Probably best to be cautious, but it's not that simple.
People complain about everything, but there's no good reason to complain about a
file or two being left behind.  Perhaps a couple of options at the start of the
process:

* Delete user settings for Firefox?
* Delete firefox folder (Path\to\firefox\)?


and if we do that, and someone is stupid enough to check that after installing
to C:\program files\ ?  still doesn't fix the issue, sadly.

Removing blocking1.0? since the blocking0.9? is still pending. If this ends up
as blocking0.9-, then request blocking1.0? again.
Flags: blocking1.0?
I got almost my entire drive hosed by this buy back on Mar 27th. Why has the win installer version not been pulled? the zipper version works great. This is ruining mozilla's reputation. I now have a distrust of any win installer release by mozilla. 

I just installed thunderbird and it is repeating the same mistake. If you accept the default path of C:/program files/mozilla thunderbird , then no problems. But a lot of folks out there don't use the default  path. When you do a custom install and browse to normally create a new folder. It tries to install to directly into programs files. So when the uninstaller tried do it's job, it ends up deleting everything in the program folder.

As everyone know, most application resides in program files, hosing almost everything on your drive. 

I cannot understand why this has not been pulled, until it's fixed. 
I think we should give an 'Uninstall options' window with checkboxes before the
actual uninstall
this will require more conscious user interaction in order to delete the base
install directory

basically have it like this:

[X] Delete profile
this will delete bookmarks etc....

[ ] Remove the Firefox folder - $folder
(red)!!warning!!(/red) this will delete the entire folder of $folder
this may cause dataloss if installed etc... only use this option if sure etc...

where $folder is ofcourse the installed folder path
How about having the installer act like NSIS http://nsis.sourceforge.net/home/ ?
When you browse for folders it automatically appends the default subfolder and
puts the whole path in an editbox whose content you can manually alter as you
like. This prevents accidental installation to the program file root but still
leaves the possibility to choose a custom install subdir. It also prevents from
having an empty directory lying around when you create a new directory and then
abort the installation as this function wouldn't be needed anymore. Directories
would only be created when the installation actually is being performed. As for
the uninstall it would defenetely be better to build a list of files to
uninstall and maybe add a few subdirs that will be wiped unconditionally
(plugins...).
we do build an uninstall log, this bug only manifests itself if you agree to 
the prompt at the end.

maybe a better stopgap would be to simply show a dialog indicating that not all 
files were removed, and give an option to open the folder from the dialog to 
manually remove those files that weren't removed?  Need to poke ben about this, 
as noted elsewhere my installer-fu is weak like little girl.
I've certainly seen other uninstallers end by saying that not all files were
removed. I don't think the option to open the folder is necessary - people can
figure that out for themselves. Even if they can't, a nearly-empty folder isn't
going to harm anything.

Ideally, we would have a situation where the folder would be empty after
removing the files the uninstaller knows about, unless something really
exceptional had happened, or the user had put something in there themselves.
I'll try implementing this into the uninstaller tomorrow.
After getting up just morning i've just noticed the function name is wrong.

Will either need to change the name or swap the returns arguements about.
That's completely unnecessary.  The function VerifyAndDeleteInstallationFolder()
at the following source location is what kills the directory in question.  if we
don't want to nuke stuff, we could simply disable this, or we could special-case
Program Files along with the systemroot.  However, that's not really a "better"
option, IMO.

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/windows/wizard/uninstall/extra.c#1870

Before 0.9, we'll be changing the profile directory, again, to Mozilla/Firefox
(and Thunderbird will change at some point to Mozilla/Thunderbird).  After
bringing this up with ben, we're probably going to do that, and also implement
something to create a folder called "Firefox" for the install if it doesn't
exist (we could also skip this for phoenix/firebird folder names for backwards
compat).  

Leaving files intact just causes problems on reinstalls/upgrades, so that's the
least acceptable option.  Its easily enough done (just skip the call at
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/windows/wizard/uninstall/dialogs.c#322)
 and be done with it.

Its ironic that no one ever made a big deal of this with the Mozilla installer.
 Maybe mozilla users are more careful and/or read dialogs? :)
I was going for the approach of removing the directory if it was empty else show
a dialog that stated that not all files were removed and the installation
directory would have to be removed manually?
"no one ever made a big deal of this with the Mozilla installer."

You make it sound like the issue has been around for years. The Mozilla
installer and uninstaller did not nuke whole folders until (IIRC) 1.5alpha. The
uninstallers in 1.4 and earlier delete only the files they install (which
generally means leaving the program folder, because talkback creates files in
its folder which the uninstaller doesn't remove).
Firefox RC .9 is out, did this bug get taken out of RC.9?
(In reply to comment #29)
> Firefox RC .9 is out, did this bug get taken out of RC.9?

Still in FireFox 0.9, I never continued with my patch after comment #26
Moving blocking0.9? to blocking1.0?
Flags: blocking0.9? → blocking1.0?
Flags: blocking1.0? → blocking1.0+
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
I believe this option should be removed, and the install-over bugs fixed by
having config.it maintain a list of files that should be removed by the
installer at install time.
Assignee: bugs → dveditz
Flags: blocking-aviary1.0RC1+
I cannot believe this bug got out in release .9!

The problem occurs when you try to specify a directory other than default. creating a new directory if it's not there would go a long way resolving this.

Is it possible to make the current unzipped version a little easier to find? 

A warning you are about to delete your entire directory would be a good stop gap. Still the uninstaller should never delete any_files that it didn't put there.

I've been posting about this problems for over two months now. If this doesn't get resolved soon, someone needs to post a warning on a more general forum (/.)
Assignee: dveditz → sspitzer
Shouldnt this now be marked a dupe of bug 237727 ?

Can the installer check that Firefox is ALWAYS installed in a specific folder
and NEVER directly in 'Program Files'? This will avoid deleteing system files.
vfwlkr - I don't see that this is a dupe. Even if the installer is changed, the
uninstaller will still nuke the folder as described here. To fix this, there
will still need to be a change to make the uninstaller not remove the folder
(best would be to remove the folder only if it's empty, as proposed earlier)
slipping into 1.0
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0PR-
My opinion on this is that:
1. the text that specifies where it is to be installed is actually EDITABLE
2. "\Mozilla Firefox" needs to be added to the selected folder if it is selected
with the search-for-folder-dialog, except for in the case where the selected
folder is already named "Mozilla Firefox" (if someone is installing over an
existing install).

Otherwise the only way to install things to a location other than C:\Program
Files\Mozilla Firefox is to pre-make the directory you want it to go to and then
select it in the installer.
This also applies to the Thunderbird installer. 
This is a very serious bug and both things I mentioned should probably be done;
The first so that if someone wants it to go somewhere else other than <selected
parent folder>\Mozilla Firefox, they can do that, and the second so that someone
can select a folder on another drive (such as D:\Program Files) and have it
automatically suggest a Mozilla Firefox subfolder.
I find the current interface for choosing an install directory to be very
confusing and, once learned, unnecessarily inconvenient to use.

Most other apps use an editable line that includes the entire address. Mozilla
does this, for example. So, when I am installing an app like Mozilla, it will
give me its default line:

C:\Program Files\Mozilla, which I can then change to
D:\Program Files\Mozilla with a one-character edit.

Other apps are also fairly clear about where they are going to install. Firefox,
once you start browsing, is not clear at all. For example, instead of being able
to choose D:\Program Files\ and having it generate the MozillaFirefox directory,
you have to create one yourself. Further, creating a new folder for Firefox gets
you a folder named "New Folder," which is renamable, but requires care in doing so.

This is all completely unnecessary. Adopting the Mozilla UI--having that
editable line with the full address--would solve many problems. Of course, the
file deletion problem needs to be solved, but there must be a reason no one ever
complained about Mozilla's having the same issue: its interface was so good the
problem never came up.
the discussion is rather off the topic of this bug. it may well be that the
solution to this is to remove this option and change the installer, but there
are other bugs for how the installer works (or doesn't work)
I second Michael Apel and Andrew Keyser's solution. This seems the easiest and
most flexible solution to me.

Also, I consider any other behaviour than that actually annoying and
un-userfriendly :).


~Grauw
(In reply to comment #41)
> I second Michael Apel and Andrew Keyser's solution. This seems the easiest and
> most flexible solution to me.

I agree as well. The current installer interface is not very user friendly, and
inflexible, installing to a custom directory can have unexpected results if you
have not used this installer before and seen the result. Appending the \Mozilla
Firefox\ directory to the path automaticaly is expected, and it comes as a
suprise when it is not.

While this does not completely solve the uninstalation issue, it does greatly
reduce the likelyhood of the problem occuring, and if I read the OP of the bug
correctly, it was the odd installation directory selection interface that caused
the root problem which led to the uninstall. 

I have had it install to a location other than what I expected before as well
due to that issue, though my data loss was not as great since I was not
installing to \Program Files\ . 

To me changing the install as suggested _and_ also limiting the uninstaller more
seems the optimal solution.
afaict there is a query on uninstall as to whether or not to remove the
directory the app lives in.
Assignee: sspitzer → bugs
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
(In reply to comment #43)
> afaict there is a query on uninstall as to whether or not to remove the
> directory the app lives in. 

If the Installer always created a Firefox folder at the location indicated by
the user then the Uninstaller will never delete system files. 

A wise development will avert the need for a smart user.
(In reply to comment #30)
> (In reply to comment #29)
> > Firefox RC .9 is out, did this bug get taken out of RC.9?
> 
> Still in FireFox 0.9, I never continued with my patch after comment #26

Any progress on this patch? It would be nice to have this behind us.

This is not a technical but a management issue: should Mozilla risk so many
man-years of effort by sticking to a techie viewpoint? Evidently the "dumb
end-user" should not try to custom install, but then the one "dumb end-user" who
does and bothches up the system can incur terrible damage to Firefox: just
imagine a headline "Firefox destroyed my system" in an eager newspaper. 

If the solution was complicated, then it might have been worthwhile to evaluate
the risk. But when it suffices to always create a "Mozilla Firefox" folder in
the location indicated by the user, why waste time? A technically saavy user can
always go back and modify the standard folder name if so desired. Playing it
safe at no cost seems to me a very good solution.


There is even a better solution now:

An MSI installer. I've used it, and it works. It works in a Windows-standard
manner and allows network installs. It is much better than the Firefox
nonstandard confusing kludge. I've been using microcomputers for more than 20
years and I've rarely seen a more annoying interface than the custom install
aspect of the current Firefox install.

The work has been done. Ditch the current method and switch--at least on Windows
machines. Check it out:

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

Both builds install easily and well, which is more than one can say for the
current Firefox method.
Yes, there are several other (safer!) methods of doing this if looking at third
party installers. InnoSetup (www.jrsoftware.org) is an installer we have used in
the past and is extremely configurable through its setup scripts.

It has built-in support for 7-zip compression of install files, as opposed to
MSI, and any other commonly used installers I've seen. It also supports
multilingual install interfaces.

A reason I'm mentioning this is also because I'm unsure of what Windows
requirements MSI has. I at least know InnoSetup supports Windows 95 to XP and
never requiring any service packs.

It has full source code available and is completely free of charge.

This isn't the right place for discussion of installer replacements - comments
here should only relate to the specific issue with the existing stuff.

The problem with either of those is that while mozilla.org's own builds could
switch installers, this is supposed to be an open source project and those
installers would an additional limitations/requirements for third parties (e.g.
localisers) wanting to make their own Firefox installer builds (AIUI, that
includes Innosetup - open source isn't enough, it needs to be licensed compatibly)
I would just like to comment that I believe this is a *serious* bug in the un-
installer. The way un-installers are supposed to work is that they remove only 
the files which the installer installed in the firstplace. Assuming that the 
program was installed into an empty directory, then attempting to delete 
everything in that directory is an *extremely* bad idea! This needs to be a 
Firefox 1.0 blocker bug as end users *will* get bitten by this.

The installer *must* be re-written so that it only attempts to remove files 
which the installer actually installs. Attempting to remove entire directories 
is a very dangerous way to have an un-installer operate!!!

In my opinion, there is no advantage to removing whole directories, as opposed 
to just removing the files we installed. If people are using pre-release 
versions of the software and need to do a complete removal then they will be 
savvy enough to be able to do the removal manually, as needs to be done with 
user profiles. I do not believe having this feature in the un-installer is a 
good idea, period. Please remove it.
Blocks: 241532
*** Bug 242118 has been marked as a duplicate of this bug. ***
The "simple" solution is not that simple, since its not a matter of just
appending "Mozilla Firefox" to the selected install path.  The number of people
who've done this is extremely small in proportion to our userbase, and of those,
anecdotally at least, most seem to have been making an assumption based on
previous usage of zip builds.

Ideally, we wouldn't install in non-clean directories either, and use a better
heuristic for uninstalling etc.  But what we have works great for 1.0, but
there's room to make it bulletproof in a non-band-aid situation.
No longer blocks: 241532
Removed? Why?

rparenton@louisianaada.org  	2004-10-07 14:04 PDT  	OtherBugsDependingOnThis  
241532  	  
(In reply to comment #52)
> The "simple" solution is not that simple, since its not a matter of just
> appending "Mozilla Firefox" to the selected install path.  The number of people
> who've done this is extremely small in proportion to our userbase, and of those,
> anecdotally at least, most seem to have been making an assumption based on
> previous usage of zip builds.
> 
> Ideally, we wouldn't install in non-clean directories either, and use a better
> heuristic for uninstalling etc.  But what we have works great for 1.0, but
> there's room to make it bulletproof in a non-band-aid situation.

All these nice considerations do not lead to a solution, and stating that what
you have "works great for 1.0" is simply mocking at all those users who have
been warning about this potential risk - because many of them have been hit at
least once, and these are users who care about Firefox and who spend time
testing it. 

What can be done ideally is not within this topic, as it will never be done.
What is needed is a modification which will avoid catastrophies.

I have a hard time to understand why adding "Mozilla Firefox" to a user-given
folder is more complicated than adding it to "Program Files" folder. If it is
really complicated, then the mechanism you are using is not good enough, since
other installers do it on a regular basis. The NIH syndrome which seems to come
to the surface was never good for progress, and should not be allowed to
undermine Firefox.


> Removed? Why?
> 
> rparenton@louisianaada.org  	2004-10-07 14:04 PDT  	OtherBugsDependingOnThis  
> 241532  	  

Because it does not effect ease of deployment and has nothing to do with that bug.
(In reply to comment #52)
> The "simple" solution is not that simple, since its not a matter of just
> appending "Mozilla Firefox" to the selected install path...
> Ideally, we wouldn't install in non-clean directories either, and use a better
> heuristic for uninstalling etc.  

1. Change text in dialogue so that it states 'chose the dir where FF dir will be
created'
2. Change default to C:\Program files
3. Add Mozilla Firefox to user choice

I see it in some installers (e.g. Kerio personal firewall), and it looks nice.
It solves some issues you mentioned fully (installing in non-clean directories),
and most of the others in most cases. And if you want to develop installer
further this is not something that prevents you from doing that.

>But what we have works great for 1.0, but
> there's room to make it bulletproof in a non-band-aid situation.
I can't fully understand that. If this can't happen then this is not the bug and
should be closed. If this could happen then it makes no difference whether the
product is in its version 1.0 or 2.0.
How about this:
"Please choose a directory for the Firefox folder to go in (C:/program files/
recommended):
+---------------+
|               |
| Tree Selector |
|               |
+---------------+
Please choos a name for the Firefox folder:
+-----------------------------------+
|Text input (Moz Firefox as default)|
+-----------------------------------+
The Mozilla Firefox program files will be installed in this directory:
[The path, in bold, goes here)"

I believe this would allow the most flexibility and would help avoid user confusion.
I disagree with the comments about choosing the parent directory for installing
Firefox. In my view the installer should specify the directory that Firefox is
actually going to be installed in, e.g. "c:\program files\mozilla firefox".
Having it set to the parent folder is both confusing and annoying, since you are
always going to end up with a sub-directory named "mozilla firefox". There is no
need to ask for both an install directory and a name for the install directory.
This is the way 99% of installers work on Windows and is not a source of confusion.

The problem is that we should *not* under *any* circumstances be deleting the
entire contents of a directory! The un-installer should politely remove the
files it installed then exit. Having an option to remove the entire directory is
both dangerous and un-necessary, hence my call for it to be removed as an option.
99% of installers do something like this: first, they have a box with
"c:\program files\mozilla firefox" and you can either change the path from there
or you can click "browse". If you do, and choose "d:\dir\blah", they update the
box again to "d:\dir\blah\mozilla firefox" and if you don't like it, you can
still edit the path in the box, or click "back" to browse again.
Look, everyone, I'm sure you think you know what's best for this bug.  Perhaps
you do.  Perhaps you don't.  I'm not here to argue either way.

/However/, I'm sure you're not the only ones who know what's best, and I'm sure
the main Firefox developers have considered the options just as much as you're
considering them right now.  Please save the rest of us (well, everyone else who
still cares about this bug -- I'm un-CCing myself in a second) the *bugspam& and
do the rest of your thinking outside of this bug report -- preferably in this
Mozillazine thread:

http://forums.mozillazine.org/viewtopic.php?t=140283
URL: http://forums.mozillazine.org/viewtop...
OK, lets all calm down for a second and think of something that can actually be
done. Major changes to the installer for 1.0 are obviously out of the question. 
A quick hack would be to error on if(IsPathProgramFiles(szTempSetupPath)). We
already do on if(IsPathWithinWindir(szTempSetupPath)) for whatever reason so
another check shouldn't be that bad.
This will at least prevent wiping out %programfiles% which most of the talk here
is about, doesn't stop someone from wiping c:\ or something though.
We'd have to get this in before localization freeze (or are we already frozen?)
so we can show a useful error message.
(In reply to comment #61)
> OK, lets all calm down for a second and think of something that can actually be
> done. Major changes to the installer for 1.0 are obviously out of the question. 

I thought major changes ARE in store for the installer. Have you seen the MSI
bug? Lately?
(In reply to comment #62)
> I thought major changes ARE in store for the installer. Have you seen the MSI
> bug? Lately?
It's intended to be an additional option. What I meant were major changes to the
_current_ installer. I wouldn't really want to risk a basically untested
official MSI installer anyway but that's up to the drivers to decide.

As a more productive comment I'll try to make a patch on the weekend but I've
never built Firefox before so better not count on it.
(In reply to comment #63)
> (In reply to comment #62)
> > I thought major changes ARE in store for the installer. Have you seen the MSI
> > bug? Lately?
> It's intended to be an additional option. What I meant were major changes to the
> _current_ installer. I wouldn't really want to risk a basically untested
> official MSI installer anyway but that's up to the drivers to decide.
> 
> As a more productive comment I'll try to make a patch on the weekend but I've
> never built Firefox before so better not count on it.

Looking forward to that.
What about removing the option to delete the install directory all together?

A simple solution that I've seen is to display a dialog at the end of the
uninstall that some files were left in the install folder.  No deletion
required.  Then it's up to the user to navigate to that folder and do a delete
all on there own.  The dialog could also contain a button that will take the
user directly to that folder, but that doesn't seem necessary for a 1.0 release.
(In reply to comment #65)
> What about removing the option to delete the install directory all together?
> 
> A simple solution that I've seen is to display a dialog at the end of the
> uninstall that some files were left in the install folder.  No deletion
> required.  Then it's up to the user to navigate to that folder and do a delete
> all on there own.  The dialog could also contain a button that will take the
> user directly to that folder, but that doesn't seem necessary for a 1.0 release.

I've seen this kind of thing also. I'm pretty sure Acrobat Reader does this.
This seems like the least harmful way to go about it.
That solution would mean that upgrading to a new version would require all users
who install anything to the install directory (plugins etc) would have to
manually remove the directory to ensure proper upgrades.  This is not an
acceptable solution to force on all users because some people make bad
assumptions and then don't read dialogs.
Does that mean this bug is WONTFIX then (leaving aside the various discussions
about installer options and stuff that don't really fit here)? Or are we hoping
that someone will come up with a miraculous solution which allows the
uninstaller to understand the user's intent without requiring them to read
anything or select any options?
(In reply to comment #67)
> That solution would mean that upgrading to a new version would require all users
> who install anything to the install directory (plugins etc) would have to
> manually remove the directory to ensure proper upgrades.

What, are users assumed to uninstall Firefox before upgrading to properly
upgrade?? I can understand it in pre-1.0 preview releases, but if Firefox can't
handle this scenario (or *requires* the user to manually remove every single
left remaint after an uninstall), there'll be a heck of a lot of problem reports
each time there's an upgrade.

Even the latest pre-1.0 builds has mechanisms to handle the problem with
leftover extensions from earlier versions, so I honestly can't see how this way
of uninstalling would be a problem when it works with so many other kinds of
software, many aimed for novice users too.
Yeah, it seems it should the responsibility of the INSTALLER to be sure the
target directory is free of junk, not the uninstaller. The uninstall system
sould simply leave non-empty folders. It should be the installer's job to
replace mis-matched versions. Plus, I thought the current builds were disabling
unrecognized plugins on first launch.
Well my patch attached will check if a directory is empty, I'll continue the
patch and add it to the uninstaller to skip non empty directories but I think
its too late for 1.0.
I'm sorry if you concider this a bugspam, but I can't help it, I have to express
my support for comment 67 and comment 69 - uninstaller should not delete a
folder (no need for a question) and installer should handle that.

One of the biggest sins of open source software is an assumption that a user
will understand dialogs and Read The Friendly Manuals. Firefox has done a
wonderful attempt to break this tradition. Please, don't make installer and
uninstaller geeky, it would be harmful without anything to gain.
I ran across this bug report while reading the help us make a list of bugs for
the next release forum posting.

Having read this bug report, I can tell you that, as a simple user, I am never
going to feel that I can upgrade safely to a new version of firefox until I see
in large letters that install/uninstall problems like this have gone away.

For widespread usage, firefox has to be idiot-proof, because many of us have no
clue about the various niceties you are discussing.  Remember the toaster model,
you bring it home and plug it in and it works.

By the way, what #39 said.

It's a fair point. On the other hand, "toaster" users wouldn't hit this because
they wouldn't be using the custom install and choosing their own install
location. It's quite possible to cause a fire, or electrocute yourself, with a
toaster if you don't use it right.  To hit this bug, the user has to be advanced
enough to choose to do a custom install and choose their own location, but not
advanced enough (and/or careful enough) to understand the consequences of not
reading the deletion prompt.
Switching to the Mozilla installer would likely produce the fewest
incompatibilities and allow a successful fix before 2004-11-09.
As a note, the code that removes the folder after prompting exists in the
Mozilla installer as well.  We actually inherited that code from the Mozilla
installer, so that's just an utterly uninformed statement.

If you think that you can switch to a different installer a day before you start
spinning final release builds for a 1.0 client then you're not thinking in
realistic terms.
In reply to comment 76:

It is true that the problem existed in the Mozilla installer. However, no one
was bitten by it due to the Mozilla installer's superior user interface. The
Firefox interface is a disaster.

Switching to a different installer is too late now. It might not have been too
late two or three days ago. It was certainly not too late on 2004-08-15, when I
first posted my suggestion (comment #39).

Regardless of the fact that switching to a new installer is too late, the
interface is really terrible. It makes a simple job hard because, for one thing
you cannot simply edit the directory line and switch the drive.

Sometimes one must admit that one has made an error, and reverse the decision
that produced it. The Mozilla installer was good enough. Moving to the current
Firefox installer was unnecessary. Sticking with it indicates pure stubbornness.
THAT is a bug that definitely needs to be fixed.
*** Bug 249056 has been marked as a duplicate of this bug. ***
There should be some sanity checking in the uninstaller, but unless people mess
with registry entries, the issue can be eliminated by the installer not letting
people install into directories that exist with a couple exceptions. The
exceptions would be if it's empty or it contains the Mozilla binaries, which
would be backed up to C:\...\Mozilla Firefox\backup. If you installed Firefox 3
times without doing an uninstall, you'd have:
C:\...\Mozilla Firefox\backup\backup containing the first installation and 
C:\...\Mozilla Firefox\backup\backup containing the second.

Mirc does the same kind of thing.

FYI back in 2002 my mom installed Mozilla Seamonkey into the C:\Windows
directory (with xpinstall) and messed up the entire system, so Seamonkey
installer isn't fool-proof but I do agree it's better -- especially since it has
a better directory selection dialog containing a textbox. Bug 123907 is an
enhancement request for Seamonkey installer (a different installer than
Firefox's) to warn when a directory exists.
*** Bug 269699 has been marked as a duplicate of this bug. ***
*** Bug 271805 has been marked as a duplicate of this bug. ***
*** Bug 272279 has been marked as a duplicate of this bug. ***
> ... the interface ... makes a simple job hard because, for one thing
> you cannot simply edit the directory line and switch the drive.

I count myself an experienced user. It took 3-5 attempts to work out how to
create a new directory and actually install in the manner I intended.  The
interface is deficient. With no lack of comments here and at
http://forums.mozillazine.org/viewtopic.php?t=140283 it's unclear what direction
this might or should take, stalemate having been achieved at comment 26. Anyway,
is there an installer summary/project page to give the average joe an idea of
what installer should do? 

Back to the bug - an INSTALL time check seems to me unobtrusive.  And for bug
testers that always want to overlay the same directory - why not add an opt out,
a checkbox of "don't prompt me again"?

p.s. target milestone is past.
(In reply to comment #83)
> is there an installer summary/project page to give the average joe an idea of
> what installer should do? 

[clarification] - "an idea of ..." what the plans are, i.e. where the installer
should be going?
*** Bug 275396 has been marked as a duplicate of this bug. ***
helpwanted should be added
When not installing to the default dir:

messagebox( hwnd,
            "We punish by potentially severe data loss "
            "for not installing this product to an EMPTY directory\n" 
            "our UNinstaller possibly nuking the aforementionned directory.\n"
            "At least you have been warned!",
            "Omg-wtf-ffs-dataloss prevention plan",
            MB_OK | MB_ICONWARNING);

Perhaps something like this? ;)
What is the bug# for FF breaking after installation over existing FF? Sorry for
asking here but I can't find it (I don't really know how too look...). It's a
pretty bad bug (the breaking-after-wrong-installation, I mean), and all these
workarounds, which consist of scary warnings, extra installer GUI, dataloss
behaviour and RTFM approach are pure evil.
*** Bug 276981 has been marked as a duplicate of this bug. ***
helpwanted applies for most bugs, but ok... adding.
Keywords: helpwanted
This bug still exists in Firefox. I installed Firefox in D:\Program Files, which
I tried to uninstall later. The uninstaller wiped off, 2/3rd of my programs.
This shouldnt be the case, no matter what. 

I didnt try to reproduce the error.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
critical data loss when it occurs, we should fix for the point releases
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Chris: We need to do a check from both ends. We need to make sure they don't
install into folders like C:\Program Files\, C:\Windows, etc (give a warning)
and also don't erase any files but the Mozilla files. It might also work to
erase file-by-file (based on a manifest) instead of just wiping a directory, and
then give them the choice of removing the directory or leaving it. This is good
if they have added files to the directory that weren't part of the installation,
or if we want to give them the choice to leave certain folders, like the
"plugins" directory. Finally, we should have a list of directories that never
get erased, and perhaps do a test to see if it's a system folder and leave it in
that case.



"I didnt try to reproduce the error."

I don't blame you ;-)
In short, I think the first step should be to make sure we don't delete system
folders, but we should follow that up by dummy-proofing their chosen
installation folder.
Right, so since we are discussiong solutions, I'm going to repeat what I had
said somewhere before: if only installer behaved at least remotely close to
expected behaviour, none of this would be a problem. In particular:
 - the presented installation path should be editable. If I don't like "c"
drive, it's a matter of one backspace and one "d" button to fix this.
 - if someone navigates to "d:\program files", the "firefox" part is appended
immiditely. All installers newer than for win3.11 do that, period.
 - if someone creates his custom directory, he should be able to select it
without tricks. Currently the newly created directory cannot be chosen for
installation (not automatically, not with the keyboard and not with an infinite
number of clicks on it).
 - uninstaller shouldn't delete files it didn't create, ever. It's up to
installer to make sure target directory is suitable for new installation, and
frankly, an application should deal with anything that might be in there.

Apologies if this isn't a helpful bugzilla comment but I can't stop myself. It's
a horrible bug, while it's easy to forget about it once you're a person who uses
.zip builds daily.
The Mozilla installer, which contained this bug for eons, never had this problem
come up. Perhaps it was due to superior user interface?

As I have said earlier, a simple and effective fix would be for Firefox to
revert to the Mozilla installer.
Please file a new bug that isn't sixteen pages long that accurately describes in
the first comment what is going on, and + that one. This one is going off my radar. 

It seems I can't edit the - flag, so I'm reassigning this to nobody@mozilla.org
to get it off my radar.
Assignee: bugs → nobody
->dveditz
Assignee: nobody → dveditz
Ben, Dan, can we just force the intall to firefox/ ? That seems like the best
way to solve this with the least pain. We need a solution pretty quick. 
I would think that forcing installation into a subfolder with a particular name
would cause pain to some people. From the previous discussion, it sounds to me
like the quickest and least painful fix would be for the uninstall not to give
the option to remove the folder (as Ben suggested way back in comment 32).
I know I sound like a broken record, but for a really quick fix, try backing out
the change that revealed the problem in the first place. The Mozilla custom
installer has the same issue, but the problem was never revealed because of its
superior user interface. 

Yes, the bug must eventually be properly fixed. But returning Firefox to its
original Mozilla custom installer would avoid nearly all user mistakes, and thus
reduce the seriousness of this bug.
Ehume, yes, you are starting to sound like a broken record :) We're not going
back to the SeaMonkey installer. There's no point in your continuing to push for
that. 

Dan, or ben, can you make a patch per dan's comment above that turns off the
cleanup?
(In reply to comment #99)
> Ben, Dan, can we just force the intall to firefox/ ? That seems like the best
> way to solve this with the least pain. We need a solution pretty quick. 

I filed this as bug 281259 some days ago and it was WONTFIXed (for the reasons
that I don't exactly agree on, but I won't fight the decision).

Just in case it matters, I vote for the widget removal (comment 32).
Attachment #174027 - Flags: review?(bugs)
Attachment #174027 - Flags: approval-aviary1.0.1?
Comment on attachment 174027 [details] [diff] [review]
Don't delete things we didn't install

r=mconnor@steelgryphon.com

definitely the right fix for 1.0.1, but I know we can do better.
Attachment #174027 - Flags: review?(bugs) → review+
Comment on attachment 174027 [details] [diff] [review]
Don't delete things we didn't install

a=asa for aviary 1.0.1 checkin.
Attachment #174027 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1+
How does one mark this as duplicate to another bug? 

https://bugzilla.mozilla.org/show_bug.cgi?id=281235
Blocks: 281235
One doesn't, in this case. I imagine the intent is for this bug to be marked
resolved based on the quick fix that's gone into 1.0.1, and for the other bug to
be for whatever further work is going to happen for 1.1. Which I think also
means it's not dependent - doing something different for 1.1 doesn't rely on the
1.0.1 fix.
No longer blocks: 281235
uninstaller band-aide checked into trunk and 1.0.1 branch. leave bug 281235 for
a more complete solution for 1.1 including installer UI changes
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
Keywords: fixed-aviary1.0.1
Resolution: --- → FIXED
Verified Fixed with Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.5) Gecko/20050218 Firefox/1.0

Only files created by the installer are deleted and the install directory
remains with the uninstall file and directory, but I'm assuming that is expected
with this bandaid.
Status: RESOLVED → VERIFIED
Depends on: 280195
Blocks: 237727
*** Bug 288701 has been marked as a duplicate of this bug. ***
Depends on: 233746
How can this be "verified fixed" if it's marked as depending on 233746 which
isn't fixed?
Those bugs (one is a duplicate of the other) were a possible solution to this
problem. This has now been fixed another way, so obviously it's not dependent -
people don't usually bother with these changes as they just create a load of bug
email and don't really inform anyone of anything, but seeing as we're creating
unnecessary bug email anyway, I'll take them off...
No longer depends on: 233746, 280195
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: