User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 There are several bugs discussing the fact that deleting a profile deletes the whole directory in which the profile was created. The problem is that this strategy has caused several cases of horrific data loss. In most cases users created profiles in the profile manager, chose to create them in a non-standard directory, then picked an existing directory containing user data (e.g. Desktop or even "My Documents" under Windows). When the profile was later deleted, not only the files created by Mozilla products but the whole directory (files and subdirectories) was deleted. The behaviour was mostly defended by developers, using arguments along the lines of "the directory chosen to contain the profile is owned by Mozilla, if users declare an existing directory to be owned by us they can't complain if we act accordingly" or "the profile manager is for experts only" (bug #270705, bug #273729, bug #302087 and more). However, various proposals to mitigate this behaviour have been looked at more favourably, like trashing rather than deleting the files (bug #18927), various redesigns of the behaviour when a profile directory is chosen (bug #95151, others discussing the order of the three buttons or making the warning text easier digestible), measures to make it harder for a user-chosen profile directory to be one with important user data (bug #304290, various ideas raised in other bugs such as warnings of it seems that a directory was chosen unwisely). But despite the arguments, and even with the implemented and most of the discussed remedies, it is still quite possible for users to lose large amounts of non-Mozilla data due to this behaviour. As a long-term advocator and supporter of Mozilla, Firefox and Thunderbird (I also have professional experience in software development and QA, but outside Mozilla), I am very worried because I have seen that it is quite easy even for little-experienced users to come across the profile manager. I would like to plea with the developers to take up the following proposal. It would make things simpler and safer for the user. The problem for developers is that the profile manager would need to know which files "its" Mozilla program produces in a profile, that extensions also need to communicate which files or subdirectories they create, and that deletion code becomes more complex because just it doesn't just delete one directory completely. When a profile is deleted and the option to delete profile files is chosen, the profile manager should: 1. make an effort to delete (maybe trash, if bug #18927 is honoured) all the files known to be created by the Mozilla product, and not more. Subdirectories known to be created by the product (e.g. chrome, extensions) should probably be deleted completely without further checks. Some subdirectories are recorded in and can be relocated by program preferences (such as mail.server.server<N>.directory for Mail, News, and such), in which case an effort should be made to delete the right ones and e.g. a "Mail" subdirectory that happens to exist by coincidence but is not actually used by Thunderbird or Seamonkey should be kept. Some extensions create their own files or subdirectories (besides the standard subdirectories within "extensions"), but unless/until there is a mechanism to query extensions for what they have created, it is probably better to err on the side of caution and not try to delete anything there. 2. If, as a result of step 1, the profile directory is empty, it can be silently deleted. Otherwise, a message should appear similar to many uninstallers: "Extra files were found in [ProfileDirectory]. The directory was not removed." Perhaps a button could be added to inspect that directory straight from the dialog. The "delete profile" dialog could probably become less "loud" about the "delete profile files" option in a way similar to the proposal of bug #95151. After some consideration I strongly think that anything less than this (and the counterarguments I quote) would be just tinkering at the edges of (or attempts to completely avoid considering) a major dataloss problem. Thanks for reading. Reproducible: Always Steps to Reproduce:

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.

A simple test would have shown you that the Firefox profile manager still behaves in the way described in this bug. You could then have done these reassignments yourself. However, I’m doing it now.

Move done. I hope the settings are now acceptable. Yes, I believe the bug is still valid and needs to be fixed. I’ve just tested it using an almost current Firefox installation (45.0) under Linux (64 bit).

I would accept a warning in the profile manager if the profile is at an unusual location. I wouldn't accept anything beyond that, since this isn't exposed UI.