Closed Bug 1526367 Opened 6 years ago Closed 6 years ago

Dedicated Profiles +1 version doesn't snatches the default profile if "Firefox is not your default browser" from Dedicated Profiles

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox67 --- affected

People

(Reporter: Ovidiu, Assigned: mossop)

References

Details

Affected versions

Affected platforms

  • Mac OS, Windows

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 check that Firefox Nightly is not set 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 snatched by the Beta version with dedicated profile feature.

Actual result

  • Modal window is displayed, and the "Important News" tab appears. If you check in about:profiles you see that a new profile is created.

Additional notes

  • This issue is a regression (dedicated profile regression).
  • This is the behaviour that is expected for when the browser is set to default on Nightly.
Blocks: 1474285

This matches what I thought the intended behaviour was to be. New versions will snatch the profile unless it has been claimed by the default browser. The rationale is that if we didn't do that the user may never start a default Firefox and so all of the installs on their computer would end up with new profiles and their old default profile wouldn't be in use anywhere.

Michael, can you confirm that this is correct?

Assignee: nobody → dtownsend
Flags: needinfo?(mverdi)

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

This matches what I thought the intended behaviour was to be. New versions will snatch the profile unless it has been claimed by the default browser. The rationale is that if we didn't do that the user may never start a default Firefox and so all of the installs on their computer would end up with new profiles and their old default profile wouldn't be in use anywhere.

Michael, can you confirm that this is correct?

Yes, this is the correct behavior.

Flags: needinfo?(mverdi)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID

If I'm reading comment 1 correctly and we fast forward ~4 weeks when beta67 launches, if I am dual channel user (running nightly and beta) when beta updates I will transition from default profile on to getting a blank default-beta profile? Summarizing, I open beta66, it downloads the beta67 update, when it restarts I will get a blank default-beta profile. Wasn't this what we were actually trying to "mitigate"?

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

New versions will snatch the profile unless it has been claimed by the default browser.

In the above example, we're going to have Nightly68 and Beta67, do we understand the newer version as Nightly68 and basically Beta67 cannot snatch the "default" profile because it's a dedicated profile for Nightly68 and thus Beta67 creates the new beta-default profile?

To add more to the mix, if in the above steps we add Firefox Nightly set as default, then what happens is that Firefox Beta will get the default profile as dedicated and Nightly will create a new dedicated default-nightly. Weren't we supposed not to "snatch" the default profile from the "default browser"?

Seems to me that the current snatching behavior is quite inverted from what were expecting. Michael & Dave, could you double check the above?

Flags: needinfo?(mverdi)
Flags: needinfo?(dtownsend)

(In reply to Adrian Florinescu [:adrian_sv] from comment #3)

First, I'm noting that there is always a bad experience somewhere in this project. We can't avoid it. But here's my understanding of how this would work with N68 and B67 as an example. There are a few (many) scenarios:

  1. Neither N68 nor B67 are the default browser. You open B67 and it downloads the update. You restart to apply the update. B68 will take the default profile from N68 because Beta was the last to use the profile (it used it even though Nightly had taken it because it didn't have the dedicated profile feature yet). Then when you start N68, it will get the blank profile.

  2. Neither N68 nor B67 are the default browser. You use N68 to download the update to B68 and you do a paveover install. Since N68 was the last to use the default profile B68 will not take it. Instead B68 will get a blank profile on startup.

  3. Same as #1 but this time N68 is the default browser. You open B67 and it downloads the update. You restart to apply the update. B68 will not take the default profile from N68 because is the default browser. This gives us the flow where you restart for an update and get a blank profile. That's pretty terrible but I'm thinking less terrible than stealing the profile from the default browser.

  4. B67 is the default browser. Whether you restart to apply the update or do a paveover, B68 will take the profile from N68 because it is the default browser.

Flags: needinfo?(mverdi)
See Also: → 1528309

Based on today's meeting we agree that the expected result from the description is the desired behaviour and also to eliminate any confusion I will close this issue as Resolved: WFM.

Resolution: INVALID → WORKSFORME
Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.