dataloss, fixed-aviary1.0.1, helpwanted
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
Last Resolved: 15 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?
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).
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.
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.
Created attachment 148594 [details] [diff] [review] Patch to check if a directory is empty 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?
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
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.
*** 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.
Removed? Why? firstname.lastname@example.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? > > email@example.com 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
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.
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.
critical data loss when it occurs, we should fix for the point releases
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 firstname.lastname@example.org to get it off my radar.
Assignee: bugs → nobody
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).
Comment on attachment 174027 [details] [diff] [review] Don't delete things we didn't install email@example.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
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
Last Resolved: 15 years ago → 14 years ago
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
*** Bug 288701 has been marked as a duplicate of this bug. ***
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...
You need to log in before you can comment on or make changes to this bug.