Firefox Needs To Support Profile Separation (bootstrap.ini)

[Guest]

1. Firefox Profile Separation (bootstrap.ini)
   
   Sorta in reply to...
   
   
   Installing Firefox 3 or Minefield while keeping Firefox 2
   ...for example in Open Office, I can install it in its own folder...
   
   
   C:\Program Files\Open Office\2.4.1
   ...then before running it I can edit...
   
   
   C:\Program Files\Open Office\2.4.1\program\bootstrap.ini
   ...from...
   
   
   UserInstallation=$SYSUSERCONFIG/OpenOffice.org2
   ...to...
   
   
   UserInstallation=$SYSUSERCONFIG/Open%20Office/2.4.1
   ...then I run the new version (via any method) & it NEVER overwrites the other version's data...
   
   I would like to be able to "bootstrap" Firefox like this...actually, I would prefer if the Firefox Profile dir was automatically bootstrapped, for example, when Firefox is installed, I'd like it to default to...
   
   
   C:\Program Files\Firefox\3.0
   ...& the Profile dir to default to...
   
   
   %AppData%\Firefox\3.0
   ...it would be good if installing Firefox to a custom dir (like C:\Firefox or whatever) would auto-bootstrap its profile dir (to %AppData%\Firefox\3.0\C-Firefox)...
   
   Yes! I have read ALL of the things about "running Firefox 2 & Firefox 3 at the same time"...all of them use the -p command line param...but this is not reliable...since ANY program that accidentally runs Firefox 3 without the -p switch will bork the Firefox 2 profile dir...
   
   I don't know what the -no-remote switch exactly does...but these bootstrapped Firefox's should automatically allow running both at the same time without needing it...for example...running...
   
   
   C:\Program Files\Firefox\2.0\Firefox
   C:\Program Files\Firefox\3.0\Firefox
   ...should load both with their own bootstrapped profile dir & allow both to run at the same time (different mutexs)...but running 2 2.0's or 2 3.0's would do what it does now...open a new window in the matching version's process...or with -no-remote it would do what it does now...so you wouldn't need -no-remote to run 2 different versions, but you would need it to run 2 of the same version...(unless it can cleanly become the default)...
   
   Using ANY method to run Firefox pointing at another version's profile dir SHOULD provide a warning...
   
   
   Warning: You are attempting to run Firefox 3.0 with a 2.0 profile directory...
   
   [Migrate 2.0 to 3.0] [Run 2.0 with 2.0 profile] [Run 3.0 with 3.0 profile] [Cancel]
   ...or something like that, allowing them to Cancel or run the correct version for the profile dir...currently Firefox happily corrupts mismatched version's profile dir without warning. However!...in a default install scenario, like non-technical users, if you install Firefox 3.0 into the 2.0 dir, the profile dir should be "migrated" without warning, since they already borked the 2.0 install dir & probably don't care about having multiple separate versions installed...or for the case above (different install & profile dirs by default) the 2.0 profile data should be "migrated" to the 3.0 profile dir (& left alone in the 2.0 profile dir)...
2. bootstrap.ini Settings
   
   In the new Firefox bootstrap.ini I would like settings for...
   
   
   • bootstrap.ini=%AppData%\Firefox\%version%\bootstrap.ini
     
     ...possibly redirecting the global bootstrap.ini somewhere else...which would allow different users of the computer to have their own bootstrap.ini...
   • ProfileDir=%AppData%\%AppName%\%version%
   • NewProcessOnRun=1
     
     ...actually this should be the default...
   • NewProcessOnNewWindow=0
     
     ...default off?...
   • AppVendor=
     
     ...or whatever variable "Mozilla" is in...
   • AppName=Firefox
     
     ...or whatever variable "Firefox" is in...
   ...changing AppVendor or AppName would basically "re-brand" Firefox, like Firesomething does...I despise calling it "Mozilla Firefox"...so I use Firesomething to change the titlebar to Firefox...as you can see above, I do not install to "Mozilla Firefox" but just "Firefox"...Mozilla is great & all, but no, I don't want them everywhere...setting AppVendor to blank should automatically remove the space that normally separates AppVendor & AppName...not have a hard coded space you can't remove...changing them in bootstrap.ini should change ALL the places they are used...like the titlebar & Help -> About <whatever>...yes I'm semi-aware there are build time settings for this, but no I cannot compile Firefox...
3. Separate Process: Profile Handler
   
   A further improvement would be to have a process handle profile data & another handle browsing...for example, in IE (yes, I know yuck) if you open a new window, it's in the same iexplore.exe process, but re-run it from the desktop (or any other method), you get a new iexplore.exe process...if one crashes, the other doesn't!...I would like this for Firefox, a way to run Firefox in a new process, without corrupting profile data OR using separate profiles OR using a cmd line param (cmd line params can't be added to "App Paths" for example {plus updating all Firefox shortcuts would be pain}...I would like this new process behavior to be default, but an option in the new bootstrap.ini would be fine too {since it would affect ALL ways of "running" Firefox.exe})...I know the optimal solution is to "fix the bugs that make Firefox crash" instead of just running a separate "crashable" process, but on the very few cases I've used IE, I like opening different sites in different processes, so if one does crash, I don't lose every site.
   
   One way to do this would be a FirefoxProfile.exe which would "handle requests" related to profile reading/writing...so you run Firefox.exe, if FirefoxProfile.exe isn't running (with a matching version's mutex {the mutexs should be based on version AND install dir}), it would start it, if it is running the new process would talk to it...on the other hand if you can simply sync multiple Firefox.exe's reading/writing to the same profile (like I guess IE does), that might be good, but a crash still needs handled cleanly, so using a separate FirefoxProfile.exe that wouldn't have a reason to crash (no site loading, no buggy plugins)...of course when FirefoxProfile.exe does crash, it needs restarted & any corruption cleaned up & the existing Firefox.exe's need to re-link to the new FirefoxProfile.exe.
   
   Doing this might make it possible to install addons/themes "without a restart"...cuz the FirefoxProfile.exe could restart (without destroying the Firefox.exe windows) & when it restarts it would re-initialize/re-paint all the windows with the new profile data...while FirefoxProfile.exe is down existing Firefox.exe's would be semi-frozen, you could interact/scroll the current page & maybe back/forward with cached pages, but anything that writes to the profile would have to wait until FirefoxProfile.exe is back up.
   
   When FirefoxProfile.exe "crashes" it should auto-restart, but "End Task"ing FirefoxProfile.exe should leave it dead, until you manually re-run it...so you could kill it/exit it, edit prefs.js, re-run it & it would read the new prefs.js (for one example)...the semi-frozen Firefox.exe's could have a msg "The Firefox Profile Handler is not running would you like to restart it?"...
4. Separate Process: Plugins
   
   It would be good to load Plugins in a separate process too...then plugin crashes wouldn't kill all the sites/open windows...FirefoxPlugin.exe...& you could restart that component without a full Firefox restart too...
5. Read-Only Mode
   
   It might be nice to have a read-only mode (not just via cmd line param), where you can specify a profile to read but not save to, so you could set that as the http & .html file handler, then selecting Help in external apps would load a read-only Firefox (in a new process)...leaving your main profile untouched...
6. Problem with all this
   
   One thing hampering all this is Firefox 1.0 1.5 2.0 & 3.0 all write to the same profile dir, so a change now only helps the future, unless they re-release previous versions with this new install scheme...I would be fine with only a 2.0 patch & 3.0 patch going forward...
7. Safe Profile Migration
   
   There should be some way to trigger Safe Profile Migration without re-installing...& without having to bork the profile you are migrating from...
8. Installer: Custom Install Options
   
   It's been awhile since I installed Firefox (I have 2.0 & have not installed 3.0 yet due to this profile issue {but I did download on Download Day to support Firefox!})...but the "Custom" or "Advanced" options on the installer need a way to specify...
   
   
   • Install dir
     
     ...it already does this...
     
     Syntax: %ProgramFiles%\%AppName%\%version%
     Decoded: C:\Program Files\Firefox\3.0
   • AppData/Profile dir
     
     Syntax: %AppData%\%AppName%\%version%
     Decoded: %AppData%\Firefox\3.0
   • Start Menu icon install dir
     
     ...I think it already does this...
     
     Syntax: %AllUsersStartMenu%\%AppName%\%version%
     Decoded: %AllUsersProfile%\Start Menu\Firefox\3.0
   ...since I don't imagine the "defaults" will ever be to my liking (versioned dirs everywhere)...it would be nice to specify all these options during a custom install, but of course just having a raw bootstrap.ini would be "OK"...currently there is NO WAY to achieve this complete separation of Firefox profile dirs...
9. Installer: Change... Support
   
   The installer needs to utilize the "Change" option & allow Changing any of the install options, which would move & re-link anything that you change...like if you click Change & change the install dir from C:\Program Files\Firefox to C:\Program Files\Firefox\3.0 it would move that directory & re-point any shortcuts related to that version...(& if the http or .html file handler are currently pointing to that version's old dir, they would be updated too)...
10. Uninstaller: Smarter
    
    Uninstalling should do the Right Thing...only uninstall the matching version's install dir (& perhaps empty parent dirs)...& the matching version's profile dir (if that option is checked during uninstall)...
11. All Software
    
    Technically I think ALL software should install this way by default (even Open Office)...versioned install dirs, versioned AppData dirs, versioned reg keys, versioned HKLM - Uninstall Keys...makes for clean install & uninstall of multiple versions...

[DanRaisch]

Moving to Firefox Features, as this is asking for a change in the way the program is intended to function.

[the-edmeister]

I agree with all 11 items (especially #6 - that was changed for version 0.9 and IMO it was better with 0.8 and prior versions, as I recall), but I would expect the Mozilla developers to remove the "concept" of "Profiles" entirely before they would even consider going with something like bootstrap.ini!

In their view (and IMO) such a minuscule percentage of Firefox users even have any idea that their data and preferences are stored in a "Profile", much less have the need for what you are proposing, that the chances of that such a major reworking of the core of Firefox coming about doesn't exist. Besides, there are two Gecko browsers - Firefox Portable and K-Meleon - that already do much of what you propose; albeit, not automatically, but at least it is more "doable" with them than with Firefox. (Profile "structure" is within the Program Files folderset, and thus is directly applicable to that one program installation.)

Sounds like a project for a 3rd-party or "community-build".


Ed