From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011125 BuildID: 20011125 One of the reasons that there is support for bug 70931 is because the automatic salting of directories changes the explicit preference of the user when the default profile directory is overridden, something that some people object to. I recently noticed that, in addition to the salting, the profile manager also appends <username> (or <profilename>) to the path explicitly defined. Therefore, it is impossible to tell Mozilla that you want the exact path, no more and no less, of "c:\Documents and Settings\<Username>\Mozilla" for your profile directory - because it will automatically tack on another, redundant, <Username> subfolder. If the choice is offered to the user to override the default profile directory, then the choice should be absolute, not something wishy-washy. If the user chooses to make the path something else, then the responsibility for it should be theirs. Mozilla has no right to second-guess, and negate, an express wish on the part of a user for a directory - a directory that has been presented as user defined in the Profile Manager UI. I opened a new report, bug 111940, on removing the automatic appending of <Username> to the path but it was immediately marked as WONTFIX - without any discussion of any kind. Therefore, I am opening this more general bug to address the broader issue. Either both bug 70931 and bug 111940 should be fixed - or neither one of them should be fixed AND the ability for the user to specify a directory other than the default should be removed. Take out the UI and hardcode the profile directory based on the <Username> and salting (for avoiding multiple profile collisions and for security). Resolving bug 70931 but NOT 111940, AND still offering the false impression that you can explicitly specify a profile directory, makes no sense. Saying, "there could be problems with letting a user specify C:\ so we won't allow them to choose exactly what they want," is the wrong way of approaching things. What if I DO want my profile directory to be at the root of C:\, knowing full well exactly what that means? (Does the Mozilla install itself prohibit you from installing the executable into C:\?) Perhaps a warning could pop up about choosing a potentially dangerous path - but it should STILL let you do so. Otherwise the UI has no business leading the user to believe that they can manually specify a directory of their choice. (They can't right now, they can only "suggest" a path, which ends up taking a form close to what they request.) Reproducible: Always Steps to Reproduce: 1. Create a new profile and try to specify a profile directory different from the default. Actual Results: You get a directory of the form <your path>\<username>\<123.slt>. Expected Results: Two options: 1. Do not present the user with the misleading "ability" to specify an alternate directory of their choice at all. (If existing behaviour is to remain.) 2. Allow the creation of the profile directory exactly as entered by the user, perhaps with the addition of popping up an alert if the directory is deemed to be "unwise" (but still allowing it to occur if the user indicates that that's their wish).
> What if I DO want my profile directory to be at the root of C:\, > knowing full well exactly what that means? _Do_ you know what it means? It means that if you ever remove that profile all the content in C:\ will be wiped out.... This is a simple case of keeping users from shooting themselves in the foot in a way from which they _cannot_recover_. setting status to NEW since this is an enhancement request...
Status: UNCONFIRMED → NEW
Ever confirmed: true
> _Do_ you know what it means? It means that if you ever remove that profile all > the content in C:\ will be wiped out.... I never said I would ever do this, or that I want to do this. I won't and I don't. I simply want to have the choice to be ABLE to do so if I wish. If I choose to put myself in the dangerous position of using C:\ as my profile directory, on my own computer, knowing the consequences, I should be able to do so. (Again, I never would, but that's beside the point.) Also, the UI is currently selling itself as letting the user have that option. It's the equivalent of a publishing company accepting an author's book - and then appending a closing chapter to it that the author neither wrote nor expected to have published. To say that you can pick your own directory, and to then put "undocumented" limitations on it, is the equivalent of false advertising. Even something as simple as saying in the UI that you can pick any directory you want - to which a subfolder named <username> will be unconditionally appended would be more acceptable (although still not ideal). At least the user would be made aware of what the program is going to do BEFORE they decide what directory structure they want. I am extremely opposed to getting something other than what is advertised as being the case. I am also opposed to have somebody else decide what's good for me. By the reasoning of "only doing what's right for somebody", we should have long ago done away with cigarettes, junk food, and recreational drugs. But part of our society is the believe that people should have the free choice to do what they want, so long as it impacts nobody else adversely, even if doing so is not, in other people's opinion, for the better.
> on my own computer, knowing the consequences My point is that 99% of the users of that dialog (and likely 50% of the ones who _will_ be changing that path) do _not_ in fact know the consequences. And there's not real way to make sure that they do.
> My point is that 99% of the users of that dialog (and likely 50% of the ones > who _will_ be changing that path) do _not_ in fact know the consequences. And Which is precisely why I say in the bug report that means should be taken to inform them of the possible consequences. Such as an alert STRONLY urging people not to pick certain directory structures and explaining why they would be bad. But, even so, the user should have the final say in overriding this if they've read the alert and accepted the consequences. (Or else, again, the UI should be changed to say that <profilename> will be appended to the path they choose as the base.) This debate is behaving EXACTLY like that for and against overriding salting. <sigh>
> Or else, again, the UI should be changed to say that <profilename> will be > appended to the path they choose as the base. I think it makes more sense to say that the profile directory will be created in the directory they choose. I think most people realize that though.
i'm not going to mark wfm because i don't have time to test this morning, but i think that you can already do what you want.
I still don't agree with this request. The UI of the profile manager is correct if you accept that a profile is a directory, not a collection of files. Aside from salting, which will be removed from any user-specified directory by bug 70931, the profile directory gets created exactly where the UI says that it will. Since this design apparently offends only 1 person, it's not worth changing given the danger it could expose users to.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
> the profile directory gets created exactly where the UI says that it will. At least change the UI to indicate to the user what you just said. That the profile directory will consist of a folder titled with the profile name. That way the program won't behave unexpectedly.
Verified wontfix (as designed). Reporter, please submit a separate bug regarding UI change.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.