[Environment:] Ubuntu 16.04 x64 Osx 10.12 Nightly 64 [Steps:] 1. Clean environment. 2. Install Firefox with dedicated in location A. 3. Run and exit Firefox from location A. 4. Install same Firefox with dedicated in location B. 5. Run Firefox from location B. [Actual Result:] 3. default dedicated is created and used for running Firefox install_A 5. default (old) is used to run Firefox install_B + downgrade page is shown since it's in the prefs.js from the old default profile which was created at step 2. [Expected Result:] When Firefox containing the dedicated profiles is ran, in my view at least, the expected result would be that for each different installation path a new dedicated profile is created and we revert to using the stub profiles when the old non-dedicated profiles are used. [Note:] 1. The downgrade page is shown due to the fact that dedicated profiles build uses the stub default profile (old) created by the initial dedicated profile build. 2. Same behavior is noted when you have a version "upgrade": version x in location A and version x+1 in location B. Attaching the profile folder for this extended case.

correcting a mistake in [Expected Result:] When Firefox containing the dedicated profile feature is ran, in my view at least, the expected result would be that for each different installation path a new dedicated profile is created and we revert to using the stub profiles when the old non-dedicated *versions* are used.

Ah yes, good catch. Because there is no compatibility.ini in the profile telling us the last install to use it I assumed we could just use it for the new install, I should probably just not do that though. compatibility.ini should always exist if a profile has been used and has useful info in it.

This should be fixed in the latest builds.

This issue is not reproducible anymore (tested on Windows 10 atm) with the updated oak builds (comment 3). Now for both cases covered in comment0, clean env.: 1. Fx64_install_path_A and Fx64_install_path_B 2. Fx65_install_path_A and Fx64_install_path_B I will get a new dedicated profile + the profile migrate page: https://www.mozilla.org/en-US/firefox/profile-migrate/ One note related to the profile migrate page, we could add a bit of polish for the instances in which this page should not be shown: first installs or no profiles existent?

(In reply to Adrian Florinescu [:adrian_sv] from comment #4) > This issue is not reproducible anymore (tested on Windows 10 atm) with the > updated oak builds (comment 3). > > Now for both cases covered in comment0, clean env.: > 1. Fx64_install_path_A and Fx64_install_path_B > 2. Fx65_install_path_A and Fx64_install_path_B > > I will get a new dedicated profile + the profile migrate page: > https://www.mozilla.org/en-US/firefox/profile-migrate/ > > One note related to the profile migrate page, we could add a bit of polish > for the instances in which this page should not be shown: first installs or > no profiles existent? Yeah, we're not meant to be showing the migrate page at all if the user only has other stub profiles present, there must be a bug here.

I reproduced this by instaling an Fx 64 with dedicated and an Fx 65 with dedicated. If I open the Fx 64 and then Fx 65 I will be prompted with https://www.mozilla.org/en-US/firefox/profile-migrate/ Should we file in another bug for this?

Yeah let's close this bug out and track issues with showing the migration first-run page in bug 1499749.