Steps to reproduce: 1. Create a new profile, use a custom folder (only way to create a profile currently (bug 16119). 2. Create a second profile, use the same folder. Actual results: Files in folder are overwritten with newest profile data. Expected results: Profilename will be a folder within custom (and/or default) folder, holding all files/folders associated with that one profile. This was true when using default folder Documents/Mozilla/Users50/profile1 etc. This can be managed by creating subfolders but it is not intuitive to do that. 4.x creates a folder Netscape Users and each profile is a subfolder within that folder. I cannot find a way to create custom folder in 4.x
The behavior is inline with our 4.x prouct. When you create a profile without picking any particular directory, the app uses default profiles folder as repository and creates a folder with that profile name. But if the user chooses to put the profile information in a location other than default location, he/she will provide information by directly typing the the name of the folder in 4.x and by selecting a folder in the apprunner. In either cases the information is stored in the directory typed/selected. Unlike the default behavior mentioned in the above paragraph, no subfolders with profile names are created. The additional thing that user need to do with apprunner is that he need to create the folder before starting the apprunner to make it available as an that can be selected. However, the majority is going to use the default folder. Setting TFV to M14, in case we decide to enhance the UI and provide more options.
Is this really a valid bug?
This one recently fixed. Got fixed with a checkin for 20198. Now the profile name always gets appended to the chosen path. Each profile can have it's own folder under the same parent. Marking fixed.
Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.