Affected versions

• Beta 67.0b1 - try build from here: https://treeherder.mozilla.org/#/jobs?repo=try&author=dtownsend%40mozilla.com&tochange=20bb0806cd97b21031aed2998bc3ee0b76ea6a4f&fromchange=2dcba8c879c5b9697c5117597fe0901bbeed203d
  Affected platforms

Affected platforms

• Mac OS 10.14, Windows 10, Ubuntu 16.04

Steps to reproduce

1. Install and open a classic Firefox Beta (no dedicated profiles) - the default profile is used.
2. Install and start Firefox Nightly the version without dedicated profiles. - the default profile is used.
3. Update Firefox Nightly to the version which has dedicated profiles. - the default profile is used.
4. Go to hamburger menu/options and set Firefox Nightly as the default browser, then close it.
5. Open the previously installed Firefox Beta. - the default profile is used.
6. Close Firefox Beta down and simulate beta update by replacing Firefox Beta without dedicated with Firefox Beta with dedicated.
7. Open the updated Firefox Beta

Expected result

• The default profile is not snatched by the Beta version with dedicated profile feature.
  *Blank profile is created for the updated Beta with dedicated.

Actual result
*The "default" profile is snatched by the Beta version with dedicated profile feature although the Nightly is set as default browser and has "default" as dedicated profile.

Ok, I have an idea of how to fix this, but it has some problems so I wanted to check if this is a case that we actually care about supporting.

This issue is a bit of an edge case, it only affects users who:

1. Update a non-default browser to dedicated profiles.
2. Subsequently set this browser as a default.
3. Then update a different install to dedicated profiles.

In this case the second install ends up using the old default profile, the original install which is now the default browser gets a new profile on next run.

The straightforward way to fix this is to have Firefox check on shutdown if it has become the default browser and if so lock the profile at that point. An alternate would be to schedule a task that does the same sometime after startup.

This does ignore the case where the user marks Firefox as the default sometime after the first run but changes that sometime before the next shutdown, hopefully we can agree that that is super edge-casey!

My chief concern here is that checking if Firefox is the default browser is not free. On some platforms it looks pretty fast but I know in at least some cases we have to spawn an external process which would block shutdown or the main thread until that completes.

So I wanted to verify how much we care about supporting this case.

I agree it's very edge case and likely not worth the expense of adding extra logic on shutdown.
I'm WON'T FIXing it

The edge case from comment 1 I think needs to be marked as wontfix, not the bug from the description. I will reopen this based on the fact that the issue from the description is valid and needs to be fixed. For the edge case issue, I think it will be ok to file a separate bug and mark it as wontfix.

(In reply to ovidiu boca[:Ovidiu] from comment #3)

The edge case from comment 1 I think needs to be marked as wontfix, not the bug from the description. I will reopen this based on the fact that the issue from the description is valid and needs to be fixed. For the edge case issue, I think it will be ok to file a separate bug and mark it as wontfix.

Can you explain the difference? I'm not sure I see it.

From what I see from the STR, Nightly is not the default browser at the time it is updated to support dedicated profiles. It is then marked as the default and then beta is updated to support dedicated profiles. This seems to match the sequence in comment 1.

The confusion was that in my scenario I have an extra step, the first one.

The issue with this bug is that if you set as default any FF version that has dedicated profiles and then you update another install to dedicated version the default profile will be lost from the browser version that was set as default.

I tested this with the try builds that you provided and I can still reproduce the issue from the description, the default profile is snatched by the Beta version.

I also tested the sceanario where the default browser is set before to update the version that has dedicated and the issue is not reproducible. I think I figured out why you consider this an edge case, because you set default browser after you updated to the version with Dedicated.
Please let me know if this is correct.

Yes this is correct. Let's close this for now. I will see if we can get any info from telemetry on how often users switch default browsers but my suspicion is that it isn't often enough to warrant action here.