1546694 - Stub installer no longer correctly detects the default profile.

Status: RESOLVED FIXED

(Firefox :: Installer, defect, P1)

Description

[Dave Townsend [:mossop]]

Bug 1369255 added logic for deciding whether to offer profile refresh for old profiles on installation. Part of that is looking at the default profile but the logic for selecting the default profile changed with bug 1474285.

Currently the installer looks for a profile with Default=1 set. This needs to change to this:

1. Read the ini value of Install<hash> Default, where hash is the cityhash of the installation directory. If not present there is no default for the install.
2. Iterate the Profile<number> sections to find the one with the matching Path.

Comment 1

[Molly Howell (she/her) (no longer active)]

Since the whole purpose of this logic is finding profiles that haven't been used with a recent Firefox version, we do still need to check for Default=1 if step 1 fails. I don't think that should complicate things too much.

For the record, this bug is a good example of why we usually try to avoid messing with profiles in the installer; it's very easy for this kind of tight but implicit coupling to break without anyone noticing.

Comment 2

[Dave Townsend [:mossop]]

Arguably we could implement this in Firefox itself.

Comment 3

[Molly Howell (she/her) (no longer active)]

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

Arguably we could implement this in Firefox itself.

For the reasoning about why we didn't do that at the time, see bug 1369255 comment 6.

Comment 4

[Molly Howell (she/her) (no longer active)]

Over the course of trying to fix this bug and wondering why things were still weird after it seemed like I had, I've also found bug 1546828.

Comment 5

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 1546694 - Support install-specific profiles in the stub installer profile refresh check. r=agashlin

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/adde7e56d8f6
Support install-specific profiles in the stub installer profile refresh check. r=agashlin

Comment 7

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/adde7e56d8f6

Comment 8

[Oana Botisan, Desktop QA]

The steps I used to verify this bug are:

1. Open Firefox and go to about:profiles.
2. Create a new profile and set it as default.
3. Close Firefox.
4. Run the stub installer and observe what profile is used to open it (by checking about:profiles).

I got two different results:

• For 68.0b14: the profile used was the "default" one (the one that is created when you open Firefox for the first time)
• On latest Nightly: the profile used was the last one that was opened.

Are these the steps I was supposed to take? And which one of these results is the expected one?

[Note]:

• On 68.0RC I couldn't perform the test because the stub installer only gets the 67.0.4 build.

Comment 9

[Molly Howell (she/her) (no longer active)]

I'm a little confused; which profile Firefox chooses to open with is a separate decision from what this bug is about. If the problem is just that there's a difference in behavior there, then that's a separate bug (assuming it's a bug at all, I'm not familiar enough with the profile manager to know what the expected behavior should be).

Comment 10

[Oana Botisan, Desktop QA]

Can you please provide me with some steps and an expected result in order to verify this fix?

Comment 11

[Molly Howell (she/her) (no longer active)]

I think this should work:

1. On a system with no Firefox profiles, install and run a 67 Nightly which has bug 1474285 (meaning at least build 20190131093752, I think). This should create a per-install default profile.
2. Run a current stub installer for Nightly 70 (needs to be at least 70 so that the version difference is at least 3).

With this bug fixed, that stub installer should show a paveover profile refresh prompt. Without this fix, it would not show any profile refresh prompt.

Comment 12

[Oana Botisan, Desktop QA]

I did the steps from comment 11 with the stub installer for the latest Nightly 70.a1 and Firefox 69.0b5. I haven't got any paveover profile refresh prompt. Firefox just simply opened with the same profile.

Comment 13

[Molly Howell (she/her) (no longer active)]

Hmm. I do get the paveover prompt when I try this. Let me be a little more specific about the steps I'm using:

1. Start from a machine with no Firefox profiles; delete %APPDATA%\Mozilla if it exists.
2. Download the full installer for nightly build 20190201093730, which satisfies the two requirements of being at most version 67 (so that it's 3 versions behind the current nightly) and has bug 1474285 landed.
3. Run that installer and then run the browser, so that a profile is created.
4. Download and run the most recent nightly stub installer.

At that point on my Windows 10 machine I see the paveover ("Firefox Nightly is already installed. Let's update it.") prompt from that stub installer, which is the expected behavior.

Comment 14

[Oana Botisan, Desktop QA]

Those were the exact steps I did, but at first I thought that I should get a prompt specific for profiles, not the one for paverover.
I tried again with the same steps and I managed to get the Paveover Prompt. But I could verify the fix only for latest Nightly 70.0a1 using Windows 10 x64, Windows 7 x32 and Windows 8.1 x32. I think this issue might be fixed.
On beta I can't verify it at the moment because of the reasons mentioned in comment 13. I will take out the qe-verify+ until the moment I can verify this issue on other builds.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.