Affected versions

• 69.0a1

Affected platforms

• Windows 10x64
• Windows 7x64
• Windows 8.1x64

Steps to reproduce

1. Install an older version(<68) of Firefox Nightly.
2. Download and install the Stub Installer for Firefox Nightly.

Expected result

• "The Firefox is already installed. Let's update it", prompt window is displayed.

Actual result

• "The Firefox is already installed. Let's update it", prompt window is not displayed.

Regression range

• Will determine if issue is a regression ASAP.

Additional notes

• After multiple attempts we have only managed to trigger the paveover prompt on Windows 8.1x64, and only with en-US and AR locales.
• Worth mentioning that for the above specified scenario , we have used builds from:
  https://archive.mozilla.org/pub/firefox/nightly/2019/01/2019-01-01-21-29-14-mozilla-central-l10n/
• However, using FF 67 from February and multiple other locales such as : de,fr,it returned no result.
• Because of this issue we are blocked from properly testing the PI-122 request.

Last Good http://ftp.mozilla.org/pub/firefox/nightly/2018/10/2018-10-24-22-13-15-mozilla-central/
First Bad http://ftp.mozilla.org/pub/firefox/nightly/2018/10/2018-10-25-10-02-46-mozilla-central/

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ddadc29de671917f66478e62a6accd4764892d25&tochange=3cc04ee79005058d817daf66da7963dfac3f0a3a

I think there might be a bit of confusion here. The trigger for the paveover prompt is when the old version is more than 2 versions older than the one being installed. So the newest version that could trigger it in a 69 installer would be 66, not 67. Can you confirm that the old versions you've been testing with are 66 or older? Thanks.

Hello Matt,

I am confirming that the the versions used in our tests are as follows: 55, 62, 65, 66.

We also tried 67 seeing as how we only got it twice for the 66 version from : https://archive.mozilla.org/pub/firefox/nightly/2019/01/2019-01-01-21-29-14-mozilla-central-l10n/ on en-US and AR locales and so we tried everything we could to see if there is some clear pattern in these builds.

Okay, thank you.

I'm going to land a patch here that improves our algorithm for detecting which existing profile we should look at to decide whether to offer a profile cleanup prompt. This won't fix all the issues, because it's impossible to detect that precisely from within the installer, and also because some of the problems (like bug 1553532) are Firefox bugs and not installer bugs. But I talked with :mossop (who worked on the per-install profiles feature) about it, and this is the algorithm he recommended:

Does installs.ini exist?
  Yes:
    Does installs.ini have a section for the install path we're using?
      Yes:
        See if the path can be resolved relatively. If not, try using it as an absolute path. If neither of those works, give up.
      No:
        Look up profiles.ini instead, look for the Default=1 entry, and use that.
  No:
    Look up profiles.ini instead, look for the Default=1 entry, and use that.

So I'm attaching a patch here that does that, and that's probably the best I can do. Hopefully it helps.

This should be more reliable than exclusively using profiles.ini, which doesn't
always get rewritten to include path hashes for the per-install profiles.

Hello Matt,

After further investigation we have determined a modality to trigger the Paveover UI with 100% repro rate using the following steps:

1.Uninstall FF from Control panel
2.Delete mozilla folder from C:\Users\svuser\AppData\Roaming
3.Delete mozilla folder from C:\Users\svuser\AppData\LocalLow
4.Delete mozilla folder from C:\Users\svuser\AppData\Local
5.Delete mozilla din C:\ProgramData
6.Delete mozilla from regedit HKEY_LOCAL_MACHINE/SOFTWARE
7.Delete mozilla.org from regedit HKEY_LOCAL_MACHINE/SOFTWARE
8.Delete mozilla from HKEY_CURRENT_USER/SOFTWARE if present
9. Install the Full version (.exe) on x64bit
10. After the install has finished, launch FF and leave the window opened and minimized.
10. Download the desired stub installer on 32bit and run it while still having the window from previous step opened and minimized.
11.Update UI is triggered.

Hope this helps.

https://hg.mozilla.org/mozilla-central/rev/995bce171fbb

Comment on attachment 9068147 [details]
Bug 1554141 - Use installs.ini to find per-install profiles. r=agashlin

Beta/Release Uplift Approval Request

• User impact if declined: Users might not get the installer's proactive profile refresh prompt when they should, increasing risk of them having problems with old extensions and such.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a straightforward improvement to an existing algorithm, and it's limited to a secondary feature not critical to install functionality,.
• String changes made/needed:

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #7)

Hello Matt,

After further investigation we have determined a modality to trigger the Paveover UI with 100% repro rate using the following steps:

[...snip...]
10. After the install has finished, launch FF and leave the window opened and minimized.
10. Download the desired stub installer on 32bit and run it while still having the window from previous step opened and minimized.
11.Update UI is triggered.

Hope this helps.

Thanks. The fact that the paveover prompt triggers in this case isn't really intended, though. If the patch here doesn't fix that, I think it needs a separate bug filed for it.

Confirming this issue as verified fixed on the latest Nightly 69.0a1(2019-05-31).

Comment on attachment 9068147 [details]
Bug 1554141 - Use installs.ini to find per-install profiles. r=agashlin

stub installer fix for 68.0b7

https://hg.mozilla.org/releases/mozilla-beta/rev/e26b8629b145

Hello,

Confirming this issue as verified fixed on 68.0b6 (64-bit) 20190529145824 and 69.0a1 (20190602221035) with Win10x64, macOS 10.14 and Ubuntu 16.04x64.

Please disregard previous comment , it was intended for another ticket!
Sorry for the confusion.

Hello,

Confirming this issue as verified fixed with 68.0b7 stub installer. Issue was tested on Windows 10x64, Windows 8.1x64.

I can still reproduce the issue on Windows 10 x64 using Firefox 68.0b8. I investigated a bit by deleting the folders specified in comment 7 one by one and tried to see if the issue was fixed.
I deleted everything I found in Registry Editor, but the bug still reproduce.
I deleted everything from the temporary files, but the bug reproduce.
Only when I deleted the mozilla folders with the profiles from C:\Users\svuser\AppData\Local - the bug didn't reproduce anymore.
Maybe this issue is reproducing because there are more then one file created and both of those profiles were used. If this is true, it might cause an issue at the moment considering the functionality of the dedicated profiles.

What version are you installing over when the prompt doesn't appear? I can't reproduce with installing 68.0b8 over 65.0b12 (which is the newest beta that should cause the paveover prompt to trigger when installing over it).

I used the 65.0b10, but I don't think that this is the issue. On another machine, the prompt was triggered when using this version.

Okay. Can you attach the profiles.ini and installs.ini files from %APPDATA%\Mozilla\Firefox on the machine that's reproducing this bug? Maybe that machine has gotten those files into some state that we don't know how to handle yet.

I managed to reproduce this issue on a different machine using Windows 10 x64 and Firefox 68.0b9. This is the files you asked for. I hope they are helpful.

Yes, thank you. We seem to be handling those files correctly. The installer picks the default install path to install into, then it looks for an install-specific profile for that path in installs.ini and doesn't find one, then it looks through profiles.ini to find the profile marked as default, which is the one named 14 in the directory j7kyfnzk.14. But since we find the correct default profile, I don't know what else could be broken. The path %APPDATA%\Mozilla\Firefox\Profiles\j7kyfnzk.14 exists and contains a compatibility.ini file, right? And the LastVersion in that file is set correctly to the old version you're installing over (I'm assuming you ran that version on this profile)?

The path is %APPDATA%\Roaming\Mozilla\Firefox\Profiles\j7kyfnzk.14 and it contains the compatibility.ini file, in which the last version is correctly set. Attached you can see everything that file contains.
Yes, I ran the old version on this profile first.

Thanks again. So, when I copy all these of these .ini files into place on a system with no other profiles present, I start getting the refresh prompts (initially it was the paveover prompt because I had a Firefox installed, but after uninstalling that one it changed to the reinstall prompt, as expected). Those files are all that we check in order to make that decision. I'm honestly not really sure what else there is that could be going wrong.

It seems that this issue is reproducible on Firefox 74.0b4, under Windows 7x64 and Windows 8.1 x64, using the same steps from Comment 0.
Taking this in consideration, I am reopening this issue.

The STR in comment 0 don't include running the old version before running the new installer, which would be necessary in order to trigger the prompt; it's based on looking at the default profile and comparing the current version number to the version that profile was last loaded into. Mihai, are you seeing this bug with that step included? I cannot reproduce it that way myself.

(In reply to Molly Howell (she/her) [:mhowell] from comment #27)

The STR in comment 0 don't include running the old version before running the new installer, which would be necessary in order to trigger the prompt; it's based on looking at the default profile and comparing the current version number to the version that profile was last loaded into. Mihai, are you seeing this bug with that step included? I cannot reproduce it that way myself.

I managed to reproduce this issue also on Windows 10 and I can confirm that "The Firefox is already installed. Let's update it", prompt window is not displayed even if the old build is opened, or not in advance. Please let me know if I can help you further with the investigation.

Mihai, can we open a new bug please, and See Also this one to it?

(this one was fixed (or partially fixed?) quite a while ago...)

(oops, see comment #29)

(In reply to Mike Taylor [:miketaylr] from comment #29)

Mihai, can we open a new bug please, and See Also this one to it?

(this one was fixed (or partially fixed?) quite a while ago...)

Opened Bug 1616834.