Windows – Really truly install multiple independent versions of Firefox

firefoxwindows

I have seen some other questions on here (e.g., this and this), plus plenty of other pages on the web, offering various strategies for installing and running multiple versions of Firefox side by side. All of them are cumbersome and/or fragile.

They all basically boil down to one of two ways, each with its own problems.

  1. Use Portable Firefox.

    • Problem: Portable Firefox only has one profile. To use multiple profiles, you have install a separate program which creates a separate profile and has to be launched separately (i.e., you aren't managing the profiles using the normal Firefox profile manager).

  2. Install a second version into its own directory.

    • Problem: All such installed versions use the same appdata directory, which means they see the same profiles. You must make sure you launch each version with a profile specially designated for it, or it may modify or corrupt a profile that was being used by another version. This means that using multiple profiles for any of the installed versions is again a risky proposition, as if you accidentally select the wrong profile, one version may step on the toes of another.

What I would like is a way to really, truly, honest-to-goodness install multiple independent versions of Firefox. By independent I mean that they should never in any way know about, interact with, or interfere with one another. I should be able to create multiple profiles for any version, using that version's own profile manager, and the versions should have separate appdata directories, so that the entire set of profiles associated with any version is completely separate from the entire set of profiles associated with any other version.

I can envision two ways of doing this, based on the two ways I mentioned above:

  1. If there were a real Portable Firefox, that would be great. By "real" I mean a portable version that actually has all the capabilities of a normally installed version, including in particular the profile manager and the ability to add/remove/select profiles without using an extra layer of PortableApps infrastructure.

  2. If I could install a normal version of Firefox but give it a different appdata directory, then it wouldn't stomp on any of the profiles of any other versions.

Is there any way to do either of these things, or otherwise get myself to a situation where I have multiple versions of Firefox installed, each of which can do everything that a normally-installed version would do, but do it all totally independently of and without any effect whatsoever on any other versions that happen to be installed?

Best Answer

A bit late on replying to this question, but anyway there goes my 2 cents.

I've been using the multi-version + multi-profile dance with FF since version 2.0 or 3.0. An added bonus is profile portability between different computers and different Windows versions. Let's see the basics:

  1. Install as many FF versions as you wish to, each in its own directory. 'C:\Program Files (x86)' is no longer the best option under Win7 (due to UAC), but I keep using it even so (out of WinXP bad habits). In this machine, for example, I have:

    • C:\Program Files (x86)\Firefox_26
    • C:\Program Files (x86)\Firefox_31
    • C:\Program Files (x86)\Firefox_38

  2. Have a dedicated folder to store your collection of FF profiles, with one sub-folder for each profile (hopefully named in whatever meaningful way, in order to avoid confusion). Again, in this machine I have:

    • D:\TJ\Fake_subst_I\FF_profiles\Profil_12.0_Main
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_12.0_PH
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_19.0_Main
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_26.0_Main
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_31.0_discard_sessions
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_31.0_Main
    • D:\TJ\Fake_subst_I\FF_profiles\Profil_38.0_discard_sessions

  3. Go inside each of the install directories and make multiple copies of firefox.exe (OFC with different names – again, meaningful names!). For example ...

    • C:\Program Files (x86)\Firefox_31\firefox(v31_test_restored_profile).exe
    • C:\Program Files (x86)\Firefox_31\firefox(v31_txyz).exe
    • C:\Program Files (x86)\Firefox_31\firefox(v31_txyz_discard_sessions_bypass_Avast).exe
    • C:\Program Files (x86)\Firefox_31\firefox(v31_zyxba_bypass_Avast).exe

    • C:\Program Files (x86)\Firefox_31\firefox.exe

      1. NOTE: the plain 'firefox.exe': I use it when I want to test one specific version of FF with a 'default' profile (mostly with ZERO add-ons).

  4. What follows requires a healthy dose of attention to detail; not really complicated, but it needs lots of copy-pasting and careful search & replace: have a collection of .BAT files that will MATCH some given version of FF with some given profile folder. I have some very long and convoluted .BATs which I'm not posting in full right now, but some key elements follow:

    set dir_applic=C:\PROGRA~2\FIREFO~3
REM
REM .BAT is happier with old DOS 8.3 filenames (when 'normal' filenames contain spaces)
REM
set dir_profil=I:\FF_profiles\Profil_38.0_discard_sessions
set ff_exe=firefox(v38_txyz_discard_sessions_bypass_Avast).exe
set coman=start %dir_applic%\%ff_exe% -no-remote -profile %dir_profil%\
REM
REM I don't like and don't use parm '-P' for 'profile NAMES'
REM
echo %coman%
pause
REM
REM ... the echo+pause lets you SEE the actual command expansion before execution
REM
%coman%
REM
REM the cooked-up command has just been executed.
REM
    1. If you noticed that the contents of variable 'dir_profil' do NOT fully match the path for the profile folder, it's because of a legacy portability issue that crept into my structures. It's not directly related to the question being replied to, but for completeness' sake I'll state that MY version of the .BAT files also have the following commands, beforehand:

    set real_drive=D
set fake_drive=I
subst %fake_drive%: %real_drive%:\TJ\Fake_subst_%fake_drive%
REM ... so that the .BAT actually goads FF into seeing a sub-folder of D: as I:

  5. The above setup allows you to run multiple combos of versions+profiles SIMULTANEOUSLY (OFC as long as the available RAM will allow).

  6. Now, for each profile, you NEED to have all the following valid; otherwise, imminent BORK is guaranteed to occur, not only within one particular PROFILE folder but also within one particular INSTALL folder. You have been warned!

    • menu Tools/Options/Advanced/Update: "NEVER check for updates".
    • don't – ever – check manually for FF updates. Again – NEVER.
    • in about:config: extensions.update.enabled = false
    • check for add-on updates MANUALLY whenever you feel the need; it's advisable to check the 'view recent updates' list in the add-on manager afterwards, to get a feel of WHICH add-ons were updated each time as well as WHAT changes were done to each (probably unnecessary geekiness).

  7. Heavily recommended as a GLUE to the whole strategy:

  8. More or less recommended (don't let the 'security experts' learn of this), depending OFC on your (mis)behaved browsing habits: resist the temptation to have ALL of FF's latest versions. You'd have to install each one in its own directory and have a NEW profile directory to match, as well.

  9. Whenever you feel the urge to have a brand-new FF version, you'd have to follow this procedure:

    • download the new version from Mozilla.org (again, DON'T use any 'update' functionality)
    • create a NEW install folder
    • install the new FF version in the newly created folder, but DON'T run it yet!
    • run the last FF version you have been using (starting from the .BAT file, OFC)
    • on that previous FF version, update all add-ons
    • run a FULL FEBE backup of said previous FF version (it will generate an optimized .ZIP file, actually named 'whatever.FBU')
    • create a NEW EMPTY folder for containing the FF profile for the newly installed FF version
    • [OPTIONAL] use 7z to unpack the 'whatever.FBU' file (the zipped profile backup by FEBE) and unceremoniously DUMP all of its contents into the newly created empty profile folder. Note: "OPTIONAL" here means: either you DO this, towards the goal of having a COMPLETE and UPDATED version of an older profile, or you DON'T do this, towards starting with a brand-new BLANK profile. Both will work, depending on what you'd want the new profile for – and in the case of the blank profile, FF will automagically populate its basic, required elements on first usage.
    • copy the 'firefox.exe' file from the newly installed FF version into its very SAME directory, now with a meaningful name (to match the new profile folder name & purpose)

    • clone your previous .BAT file into a new one, where you'll carefully replace the contents of the following variables:

      dir_applic (if containing spaces, use its 8.3 DOS notation)
dir_profil
ff_exe

    • run the newly cloned & edited .BAT file, so that a RENAMED firefox.exe from the NEWLY installed FF version will reference the NEW just-filled PROFILE folder (while OFC totally ignoring and preserving the previous FF versions and each of their corresponding profiles)

    • this is the moment of TRUTH where FF will check all of your add-ons for compatibility, disable a few of them, recommend new versions of some others etc. etc etc.
    • whenever you're done with massaging add-ons in your newest profile, go to next item!

  10. Since FEBE's settings contain a DESTINATION folder for profile backups, you should now change it from its previous value, so that from now on any new FEBE backups will get stored in a folder different from the backups of the previous FF version.

  11. Generate TWO FEBE backups: one itemized and one all-in-one. Verify that both backup sets ended up in the NEW destination folder (i.e., NOT together with the backups from the previous profile-version combo).

  12. Create – and test – a shortcut somewhere, pointing to the newly tested .BAT file.

  13. Have a sigh of relief, and/or blame myself for such a complicated and involved procedure.

Cheers & good luck!

Edit on July 5, 2015, to clarify some issues raised in a comment by the OP to my proposed solution above:

A. If I "run one of the various firefox_xxx.exe files without specifying a profile on the command line" ... it would [try to] run the 'default' FF profile of my Windows user, i.e., the profile located inside "C:\Users\myusername". Results would be random, depending on which version is the current FF .exe running the default profile and on which version was the previous FF .exe that attempted a previous run on same default profile. Remembering, in my scheme of things, that:

  • none of my assorted firefox_xxx.exe files is meant to be run without a proper .BAT file;
  • my default FF profile sits there just for TEST purposes, such as comparing a cleaner FF environment with one of my typical others with dozens of add-ons, and is not meant to be used regularly.

B. The "check for updates" button is not meant to be pressed in my scheme of things. However, in a hypothetical situation where it would be pressed, the following would happen, approximately:

  1. let's suppose I'm running a particular .BAT file which invokes an install of FF 31, coupled with a particular profile which has been tailored for FF 31:
  2. the update would actually update the version of FF located in "C:\Program Files (x86)\Firefox_31" to, let's say, FF 39, including the ORIGINAL firefox.exe and all supporting files present in that install directory;
  3. the renamed 'clones' of firefox.exe in that same install directory would REMAIN at v31, and any attempt to run any of these executables – now surrounded by a set of supporting files which are all now updated to FF 39 – would probably throw an error, or not start the browser at all.
  4. the update would also scan the profile directory pointed to by the .BAT file, validating and invalidating add-ons as seen fit to be run with v39, and most likely crippling that profile directory for any future use with the original v31 it had been tailored for;
  5. all my other installed versions of FF (which live each in a specific install directory) would remain untouched;
  6. all my other existing profile directories would remain untouched, including any others I might have which had been made for FF 31;
  7. if, for example, after this undesired update of FF 31, I then run my specific .BAT file which invokes my install of FF 38, coupled with a particular profile tailored for FF 38, everything would be still untouched and run perfectly;
  8. OTOH, if I now attempt to run ANOTHER .BAT file which would invoke FF 31, coupled with a DIFFERENT profile which has also been tailored for FF 31, I might have unpredictable results – because, while this different profile directory would still be intact as a 'v31' profile, the INSTALL directory of FF 31 now contains a full FF 39 install, together with cloned .exes which have remained at v31. This .BAT file would, in this case, be calling one of the 'leftover' v31 .exes.

C. As I expect to have demonstrated above, your statement "If updating one install affects other installs ..." is not true, and therefore your conclusion "the installs are not fully independent" is invalid.

D. The lockpref approach which you've linked to is aimed to be used in an environment where there's an 'admin' which needs to prevent undesired actions by 'common users'. My solution, OTOH, is a construct created by a geek for its own use, and as such it assumes not only strict and careful usage parameters, but also an absence of other users who might bork it thru careless usage.

Related Question