Affected versions
*Fx 77.0a1

Affected platforms

• Windows 7 (Virtual Environment)

Steps to reproduce

1. Fresh Virtual Environment (so no Registry entries for Firefox and no old profiles)
2. Install Fx 73.0a1 .exe (2019-12-01-09-37-32) Standard install.
3. Open Fx.
4. Click on hamburger menu.
   5.Options and general.
   6.Uncheck automatically install updates and install updates using background services
5. Browser reddit.
   8.Close Firefox.
6. Run the latest nightly stub installer (2020-04-27-09-43-22)

Expected result

• The update prompt is displayed.

Actual result

• The install prompt is displayed and if let to fully install, Firefox opens and says it was updated to the current version of 77.0a1

Regression range
Will try to find one ASAP.

Additional notes
*This may or may not be related to using a VM as another colleague had the same problem on an Windows machine 8.1 but could not debugg to this extent.

*Also we could not reproduce this on other Windows machines.

I wasn't able to reproduce this using those steps on a newly created 64-bit Windows 7 SP1 VM; I did get the update prompt.

One point that might be complicating matters here: there's an automatic background update check that happens immediately on startup if you're running a nightly that's more than two days old, and that check could have happened and even staged an update before you were able to turn off the automatic install setting (I definitely noticed that had happened when I tried). But that would have needed the browser to be started a second time in order to finish applying that update and also to update the profile before the installer's prompt would be disabled because of it, so I'm not sure that's really the problem. I don't have any other ideas right now though.

I could try creating a new profile with a user.js with background update check disabled, install Fx old version and open it with that profile and then try to use the stub installer, would that help?

I don't think that would work, we don't implement that setting as a pref anymore (as of bug 1458308). But you could try to do the same thing with the file that's used instead now, which will be called C:\ProgramData\Mozilla\updates\<hash>\update-config.json (there should be only one <hash> directory if there's only one installation on the machine); change the setting the usual way once to generate that file, then make sure it stays in place. That would at least eliminate that update as a possible factor here.

So I tried what you suggested and this is what I found:

1. I deleted the Mozilla folder from Roaming and Local.
2. I uninstalled Fx.
3. I deleted <hash>'s folder because there were more hash folders.
4. Installed Fx 72. Checked "Check for updates but let you choose to install them" and clicked on discard when prompted also unchecked use background services to install updates and automatically update search engines.
   4.1 (The update-config.json exists)
5. Ran the latest Nightly stub installer it reaches 60% (more or less) then the hashed folder disappears.
6. Firefox opens its the update page and the hash folder is empty.

Thanks. That's not exactly what I meant (I was trying to make sure that update-config.json was in place before running 72), but it doesn't matter, that test is still enough to show that the thing I was thinking about isn't the problem (because the "Discard" dialog removes the update I was thinking might have gotten applied).

I am a little concerned though that there were multiple update directories; one of those gets created for each installation path, so if there's more than one that means there's more than one installation. That makes me wonder if the two installers are not using the same path for some reason, which would mean the stub is skipping the update prompt because it doesn't find a profile for the installation it's actually about to create. Can you check on that?

Hello,
I am really sorry for the late reply had some hardware problems. The multiple updates directories were from previous test runs as I had used the VM all day for testing the stub installer (different locale stubs, installing and uninstalling, cleaning HROOT keys etc.) so maybe that would explain why there were so many folders. In my previous reply were I managed to reproduce the bug I deleted those folders and only had one update folder and was still able to reproduce the issue.

I can try to do the test a few more times and see if that would create more updates folders.

Thanks. Can you double-check that the first and second installations aren't being created in different places (as in, there isn't one in Program Files but another in Program Files (x86) or something like that). I'm having a hard time thinking of another way this could be happening...

Hello,

I tried again and I couldn't find any evidence of there being more installations. Unfortunately I'm also out of ideas.

Thanks for checking! Could you please attach the installs.ini and profiles.ini files (in %APPDATA%\Mozilla\Firefox , %APPDATA% should be C:\Users\<User Name>\AppData\Roaming)? That's what strikes me as the most fragile part of the logic, maybe there's something unexpected going on in these INIs.

Also, to ensure that 72 doesn't try to update itself, it might be helpful to disconnect the network on the VM. Once 72 has run and exited this can be reenabled in order to use the stub.

Hello,

I added the files. I tried what Adam suggested by stopping the internet connection when I installed 72 made a profile existed then turned it on when i used the stub installer, but unfortunately no update prompt was received.

The priority flag is not set for this bug.
:agashlin, could you have a look please?

For more information, please visit auto_nag documentation.

Thanks again, unfortunately everything looks normal in those files. Is it possible to send over the VM image being used (or link to where you got it from if it is online)? I don't know what else specifically to check, I'd just be running through the profile detection code line by line.

Marking S3 as this is not essential functionality, even if it isn't great that it is broken here.

Oh, another important question: If you use an older Nightly stub from before the web based UI landed, does the paveover prompt show?

Hello,

The image I used for this VM (a windows 7 vm on Ubuntu 18.04) i also used on my main Win 10 PC so i don't think that's the problem.
As for the other question i just tried installing 71.0b8.exe and used the 71.0b8 stub installer and i still could not get the paveover prompt.

Ok, I wanted to eliminate the possibility (suggested in the summary) of it being related to the web stub.

It's really strange that it doesn't happen in different instances of the same VM. I wonder if it could be a network issue, the stub tries to get the latest release version from https://product-details.mozilla.org/1.0/firefox_versions.json, can you access that on the troublesome VM? It should fall back to the version of the stub in that case, but maybe it is failing in an odd way.

Hello,

I dont exactly know how to do that, if you can provide some instructions on how to verify this, I would appreciate it.

It doesn't seem likely to be the issue, but if you want to check you'd go to https://product-details.mozilla.org/1.0/firefox_versions.json in a browser on the machine, just see if it loads.

Hello,
Sorry for the long delay had to work on other features. I can load the json on every browser in the VM.