1523687 - Some Windows 7 machines don't receive WNP all of the time - intermittent

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect, P3)

Description

[Bogdan Maris, Desktop QA]

Affected versions

• Firefox 65.0 RC

Affected platforms

• Windows 7 32bit & 64bit

Steps to reproduce

1. Download any old RC build (eg. 56.0-win32-en-US)
2. Start Firefox
3. Go to About Firefox window so the update is triggered
4. Restart Fx so that the update is applied and latest version of Fx 65.0 is displayed.

Expected result

• When updating to Fx 65.0 Users should receive a what's new page.
  eg: https://www.mozilla.org/en-US/firefox/65.0/whatsnew/?oldversion=59.0

Actual result

• In some cases on some machines the WNP is not displayed at all, unfortunately this is intermittent. Following the steps multiple times would result in triggering this hopefully.

Regression range

• I don't think this applies here

Additional notes

• release-localtest and release-cdntest are also affected by this behavior, not strict related to release channel.
• Update.xml from an update that did not display WNP: https://drive.google.com/open?id=1tybiL0htJmTVMyRLkMKnuWbBIDNJdPr3

Comment 1

[Robin Steuber (they/them) [:bytesized]]

I have a suspicion as to what could be going on here.

For background, the update directory was migrated, on Windows, from a user-specific location (e.g. C:\Users\<user>\AppData\Local\Mozilla\updates\<hash>) to an installation-specific location (e.g. C:\ProgramData\Mozilla\updates\<hash>) in Bug 1458314, which merged in Firefox 65.

I see this line in the update log that you linked to:

AUS:SVC UpdateServiceStub:_migrateUpdateDirectory - migrated and unmigrated update directories found. Deleting the unmigrated directory

This makes me wonder if the problematic updates could be a result of updating when an installation with the same install path already underwent update directory migration. If, when migrating, Firefox sees that the new (post-migration) update directory already exists, it assumes that migration already occurred for this installation, possibly as another user. It therefore and cleans up (i.e. removes) the old update directory rather than migrating those files to the new update directory. This would have the result of preventing the post-update actions such as displaying the "What's New" page.

Does this match what you are seeing? If this is the case, you should not be able to reproduce the problem unless the new update directory exists prior to updating.

If you need to locate the update directory for an installation, you can run this in the browser console:

Cc["@mozilla.org/updates/update-service;1"].getService(Ci.nsIApplicationUpdateService).getUpdatesDirectory().path

If you run it on pre-65, this will give you the old update directory rather than the new one, but it can help you figure out the path hash, so that you can locate the new update directory in C:\ProgramData\Mozilla\updates\<hash>

Comment 2

[Stefan [:StefanG_QA]]

I think your thoughts are correct. Every time when we install Firefox to a new directory it correctly displays the WNP for it. However, if we delete it and install it again in the same directory, Firefox does fail to show the WNP and the below error can be observed in the browser console:

"UpdateUtils.getAppUpdateAutoEnabled - Unable to read app update configuration file. Exception: Win error 2 during operation open on file C:\ProgramData\Mozilla\updates\6CF359F4EE0FA20D\update-config.json (The system cannot find the file specified.)"

Comment 3

[Catalin Sasca, Desktop QA [:csasca]]

Hi Kirk, so I think that the update directory doesn't have a part here (I may be wrong), because while testing I used only zipped packages, not the installer. I was just unzipping them on the desktop, and trying to get the WNP after updating the browser. I tried on three different computers, on two of them, never triggered the WNP (tried a couple of times on both systems), but on the third one, on the first try, it successfully launched with the WNP, and after deleting the browser and unzipping it again on desktop in order to trigger the WNP again, I was out of luck, and never got it to trigger again. This has happened on Windows 7 x64 and x86. If you have any other questions, please let me know. Thanks.

Comment 4

[Robert Strong (they/them - no direct email)]

It won't migrate to the new directory more than once based on several conditions. One of the conditions is a pref with the prefix of
app.update.migrated.updateDir2.

that will contain a hash of the install dir path.

Clear that pref from the profile and delete the new update directories under %allusersprofile% (copy and paste that into right click start->run or however you get to that for the version of Windows you are using. Under the Mozilla directory will be an updates directory.

Remove both of those and then try to update.

Comment 5

[Catalin Sasca, Desktop QA [:csasca]]

So, I think that the update directories under %allusersprofile% may be problem here. After deleting the folder, from the first attempt to update, I got the WNP at 65.0, but at the second and third attempt, I got no WNP while using new profiles everytime. After that, I deleted again the directory under %allusersprofile% and again, it got me the WNP while updating to Fx 65.0.

I used Fx 56.0 (x86) on Windows 7 (x64).

Comment 6

[Robin Steuber (they/them) [:bytesized]]

This appears to be a known side-effect of Bug 1458314. It should not prevent the WNP from displaying on the first FF64->FF65 upgrade; it should only happen after downgrading and re-updating. It sounds like everyone experiencing the problem is corroborating this.

Therefore, I consider this behavior to be acceptable.