Closed Bug 1546694 Opened 8 months ago Closed 8 months ago

Stub installer no longer correctly detects the default profile.

Categories

(Firefox :: Installer, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed
firefox69 --- fixed
firefox70 --- verified

People

(Reporter: mossop, Assigned: mhowell)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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.

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.

Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Priority: -- → P1

Arguably we could implement this in Firefox itself.

(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.

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.

Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/adde7e56d8f6
Support install-specific profiles in the stub installer profile refresh check. r=agashlin
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

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.
Flags: needinfo?(mhowell)

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).

Flags: needinfo?(mhowell)

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

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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.

Flags: qe-verify+

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

You need to log in before you can comment on or make changes to this bug.