[Affected platforms]: Tested on Mac OS X 10.12 and Windows 10 [Steps to reproduce]: 1. Open an FF Nightly 64 without the fix - in about:profiles there is the default profile 2. Overwrite the FF Nightly 64 with FF Nightly 65 with the fix 3. Open FF Nightly 65 [Expected result]: The build should open with the default profile [Actual result]: The 65 build is open with a new "default" profile Note: We consider this case as a blocker for now because it will affect all the users that will do the update from the older build without the feature to the newest one that has the feature.

Aside from a startup crash on the OSX 65 build which seems unrelated I've been unable to reproduce this issue. The previous default profile correctly gets migrated to be the new default for the 65 build. Can you give some more detailed steps to reproduce and also provide copies of compatibility.ini from the original default profile and the profile that 65.0a1 ends up using.

Steps to reproduce: 1. Install an Fx 62 release and open it, in my case I didn't have any other FF build installed, so you have only the default profile. 2. I downloaded an Fx 64 with the fix (didn't open) 3. Go to FX 62 "Show Package Contents" and delete the "Content" folder. 4. Go to FX 64 "Show Package Contents" copy the "Content" folder and past it into Fx 62 folder. 5. Open FX 62 and verify in about:profiles how many profiles have been created. Here are the results from proifles.ini ---- https://docs.google.com/document/d/1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit Please let me know if these steps are clear enough.

Please note that the same behaviour is generated if I run this steps using a Nightly 64 without the fix and a Nightly 65 with the fix.

Seems straightforward enough, not sure why I can't reproduce this. Can you attach profiles.ini from before you run the updated build and profiles.ini and installs.ini from after you run it?

Hi Dave, here is a screen recording: https://streamable.com/hj59g I will provide the other data tomorrow, thanks.

I updated the gdoc with the information from comment 4, here: https://docs.google.com/document/d/1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit

(In reply to ovidiu boca[:Ovidiu] from comment #6) > I updated the gdoc with the information from comment 4, here: > https://docs.google.com/document/d/ > 1tR2GVhgvWu27ms299W6KStKxZxLpV1_wtzRNnO2h4Do/edit installs.ini looks bigger than I'd expect after only running a single build with the dedicated profiles feature. Are you clearing that before attempting to reproduce?

The results using the latest custom Nightly build 64 send us on email https://docs.google.com/document/d/1oP62JpClJwxPjLU-DibgMZjgEzPIHWzlAcDQCykNxAo/edit

Dave, based on our latest tests, I think this bug is fixed now and can be marked as resolved.

Fixed in the latest builds.

I retested this issue with the latest try builds send by Dave via email and the issue is reproducible again. Based on this result I will reopen the bug. Please note that The try builds where the issue is reproducible (the latest ones): Trunk 64.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4156ab7b5c10014cfc21727e86a2924cdc84b0ba Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=df779b4756a29cdb504e90b4d062bca4f5b62be0 Beta 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b39c723398f6765325e68eb60c3ae49f40c3aed Devedition 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=877402c322d6c150e1516a83f376afae27cfbaf5 The try builds where the issue is not reproducible: Trunk 64.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e67cb60333b9b8458bae808f75ba41cd250edaa9 (the OSX build failure is ignorable here) Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f742723910a814c8a4db7915240eaadeb083c245 Beta 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f5f75083d310234541e6afa1506265cce810013 Devedition 64.0: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b3480c31a066f70465694d1d24703b6e69688555 (I'm investigating the linux build failure here)

I'm struggling to figure out a way to reproduce this. Is it reproducible in a VM? If so getting it into the state immediately before running the new build and then getting it to me might help a lot. Alternatively do the following: 1. Wipe the Firefox profiles location (including any profiles.ini and installs.ini). 2. Launch and exit Firefox 62. 3. zip up the entire profiles location (including profiles.ini). 4. Run and exit the updated build. 5. zip up the entire profiles location (including profiles.ini and installs.ini). Then send me both the zip files and let me know the exact OS you were running on.

The link from the folder with the entire profiles location (including profiles.ini)from Fx 62 https://drive.google.com/drive/folders/1WZ21GrRoQQ8qH6aaBa_LdBxX1sKNb_o5?usp=sharing The entire profiles location (including profiles.ini and installs.ini) after the update to Try build 65: Trunk 65.0a1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=df779b4756a29cdb504e90b4d062bca4f5b62be0 https://drive.google.com/drive/folders/1_IfxF_r38l5WrHOJ-Jpzq-wKsIW74gt4?usp=sharing I used iMac OS X 10.12, I don't have access to a VM.

Marking as fixed per email.