Basicly, if bug 12911 was fixed and mozilla was using relative pathnames for all components of a profile, it would then be possible to implement relative profile pathnames. Once thats in place, then you add a new setting thats global for mozilla and is stored somewhere that tells mozilla to look in folder xyz for profiles instead of (for example) c:\documents and settings\username\application data\mozilla\profiles. Each folder under the folder you specify would be then treated as a profile and offerd for selecton in the profile manager. mozilla would inspect each folder to identify if it is in fact a profile (by checking that prefs.js is there and can be read perhaps) This would allow you to share a profile between different operating systems or different PCs. Roaming profiles could also use this same feature in that every user is given a profile folder on <somenetworkdrive>\profiles\username that is readable and writeable by them. Each machine that needs to access the roaming profiles would have the setting for profile folders set to <somenetworkdrive>\profiles When the user loads up the browser, it would go to <somenetworkdriver>\profiles and check each profile folder to identify if its a profile or not (as specified above). Profile folders that it cant read (i.e. everyones but those that whoever is logged in has access to) wouldnt be displayed. Another thing you could add is a setting that, when set one way would tell mozilla to scan, when set the other way would tell it to prompt the user for the name of a profile to load from whatever "profile folder" mozilla was configured to use. In the case where the user has a home folder on a server, you can just "mount" that folder over the network as a drive letter (on windows) or a path (on unix). Each users home folder would get mapped to the same path at login somehow (on windows its easy to do) then the "profile path" would be set to that constant path.
oops, that shouldnt be bug 12911 in the earlier comment that should be bug 137006. marking 137006 as a dependancy
see bug 141780 (this appears to be a duplicate of that bug) and also checkout its comment #4: http://bugzilla.mozilla.org/show_bug.cgi?id=141780#c4 "Another thing you could add is a setting that, when set one way would tell mozilla to scan, when set the other way would tell it to prompt the user for the name of a profile to load from whatever "profile folder" mozilla was configured to use." this is covered by Roaming Profiles bug 124029
124029 is about implementing 4.x style roaming profiles which are totally different things to what I describe here. 141780 isnt a duplicate as far as I can tell from reading it, its related though. let me explain how this would work. (pretend for a moment that 137006 has been fixed and that all profile components are using relative paths) 1.user installs mozilla under one operating system and creates a profile. That profile goes in a folder, lets call it x. under x will be profilename\xyz.slt 2.user installs mozilla under second operating system or on second PC. User then uses new profile manager setting (could be stored in registry.dat) and sets it to the full path (may be a network path like \\computer1\c\xyz, dont know if mozilla reads those though) to folder x as seen by computer 2\operating system 2. Profile manager running under computer 2 or operating system 2 then scans the path provided, scans each subfolder to identify if its a valid profile or not (one possible way to check is to read prefs.js from profile and somehow check that its valid) Then all valid profiles are displayed and the user selects one, just like if it was in the local location for profiles. If a new profile shows up, it will be picked up by the next startup scan. Mozilla will use the selected profile and read and write all data from/to it. another case of this would be when the user is on a network and has, say ,a writable home folder mapped to a drive letter or path or whatever. When the account is created, a default profile of some kind, perhaps customized to the user for email and stuff, is copied to the home folder. Then all machines on the network are setup to use whatever the home folder is mapped to as the "profile root folder" I am talking about. The final case would be where the profile folders are all stored on the local network server like the second case but they are in some central repository for example \\computer\profiles and then you have a folder yourname under that with the xyz.slt folder under that. This is assuming that there isnt a network map directly to \\computer\profiles\yourname set up already. In this third case, you might not want to have it do the scan (especially if there are many profiles) so you have an extra checkbox or option that, when checked, tells profilemanager not to scan but instead to ask the user to input the profilename (possibly you could also have a 3rd option that would use the username from the windows environment to find the profile i.e. profilename = username). After its gotten the profilename from the environment or the user, it would load that profile from the "profile base directory" specified in the settings. Note that all this is based on what I understand from a windows perspetive (I havent used mozilla on mac or unix so I cant speak about the profile code on those platforms) just to explain a bit more, on XP, all profiles go into c:\documents and settings\my username\application data\mozilla\profiles The "profile base directory" that this bug specifies a means of changing is that base folder (which in turn has all profile folders)
I thought that what you were asking for had been discussed as part of providing Mozilla Roaming Profiles; it isn't exactly what Roaming Profiles is but this procedure of loading a profile from a location is covered by the work being done on Roaming Profiles, or so I'd thought. and that would provide solution to some of your request; but it wouldn't provide the ability for Mozillas on differing operating systems to automatically scan for profile directories below a given folder, but I think the ability to load a given profile from a given location covers this well enough as a workaround the reason I pointed to comment # 4 of bug 141780 is because I thought that, atleast under Windows NT4/2000/XP, as Mozilla uses the Windows Profile directory, and as you are able to move that directory to wherever you want, then you are less likely to need to move the Mozilla profile directory independently of this maybe this still doesn't do it for you :)
15 years ago
It would be nice to pass the location of all profiles as parameter or via registry/configfile located in the mozilla installation directory. The profiles should be password-protected too :) e.g.: mozilla --profiles-home=D:\common\mozilla\profiles --profile=my_name (-- password=xyz) thunderbird --profiles-home=D:\common\mozilla\profiles --profile=%USERNAME% this would lead to look for the profile under D:\common\mozilla\profiles\my_name\