[Environment:] Reproduced on Firefox 64 - dedicated version (https://treeherder.mozilla.org/#/jobs?repo=try&revision=e67cb60333b9b8458bae808f75ba41cd250edaa9) Ubuntu 16.04 Osx 10.12 Windows (not tested yet) - most likely affected [Description:] Current assertion about how new dedicated profiles per installation works: Clean environment, first run with dedicated profiles per install: - 3 profiles are created: default-dedicated default (for older without the dedicated feature) default-dev-edition (for older without the dedicated feature) When Dedicated profiles detects that one of the stub profiles are missing from profiles.ini, it creates both of them, instead of just creating the one missing. [Steps:] 1. Clean environment. 2. Install dedicated profiles version, run it and exit (without profile manager). 3. Open profile folder and from profiles.ini delete default (old) or default-dev-edition (old) 3. Open profile manager and delete default (old) or default-dev-edition (old) without deleting the files. 4. ReOpen Firefox with dedicated profiles. [Actual Result:] For example, if you deleted the default profile from profiles.ini, in profile folder you shall have now two dev-edition-default profiles and 3 default profiles but the profile manager and profiles.ini will see only one default (new dedicated) and one stub dev-edition-default. [Expected:] A. profiles deleted from profiles.ini not to be visible in profile manager / firefox B. profiles added from within Firefox/profile manager functionality to be visible in Firefox/profile manager. C. profiles added as part of Dedicated profiles functionality to match the profiles ini D. profiles that are added for the stub profiles to meet the needs: if dev-edition-default is missing, add just that, not the pair (default + dev-edition-default). [Note:] Adding an archived bad state of the profiles folder(from Ubuntu). Setting -- flag for Fx64 to reflect that since the feature is not yet landed on mc, this doesn't affect Fx64.
I think this looks better with some updated builds I'll send along later today. But there are a couple of things to note when trying to reproduce: (In reply to Adrian Florinescu [:adrian_sv] from comment #0) > [Steps:] > 1. Clean environment. > 2. Install dedicated profiles version, run it and exit (without profile > manager). > 3. Open profile folder and from profiles.ini delete default (old) or > default-dev-edition (old) Please make sure that unless you're removing the last profile in profiles.ini that you're re-numbering the later sections. The profile manager has always ignored non-sequential profile sections in profiles.ini so those profiles get dropped on the floor. > 3. Open profile manager and delete default (old) or default-dev-edition > (old) without deleting the files. At this point, on startup, we see that one of the stub profiles is missing so we re-create it. That might be the wrong choice, but at the moment I'm being aggressive on ensuring the stub profiles already exist. That probably looks confusing so we should discuss with Romain if that is the right choice or not, I'll start an email thread about it. So as soon as the profile manager shows there are now two folders for the stub that got deleted, the one that used to be referenced in profiles.ini and the one created on startup. When you remove the newer one from the profile manager UI it flushes stater to disk, which again re-creates stubs that don't exist so you end up with a third stub for whatever one you've been deleting. > 4. ReOpen Firefox with dedicated profiles. > [Actual Result:] > For example, if you deleted the default profile from profiles.ini, in > profile folder you shall have now two dev-edition-default profiles and 3 > default profiles but the profile manager and profiles.ini will see only one > default (new dedicated) and one stub dev-edition-default. That there are two dev-edition-default profiles is the surprising bit for me. It could be the result of not renumbering profiles.ini causing one of the stubs to be "lost" and recreated on startup or there could be another bug I'm missing. Please re-check this with the latest builds I send along later.
Can you re-test here?
I did a quick check on Mac OS 10.12 and at the moment I can say that this issue is no longer reproducible, we will investigate this in more details later on and we will let you know the output.
Sounds like this is fixed.
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.