Open Bug 1891812 Opened 2 months ago Updated 2 months ago

Firefox in-browser updates are incomplete

Categories

(Toolkit :: Application Update, defect)

Firefox 124
defect

Tracking

()

UNCONFIRMED

People

(Reporter: DGnani, Unassigned, NeedInfo)

Details

Attachments

(1 file)

7.16 KB, application/x-zip-compressed
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

Under main menu Help>About I activated the update from Firefox 124.x to Firefox 125.0.1

Actual results:

As many times before, after the update completed and the browser restarted, portions of the application were not updated: under control panel 'Programs and Features' two versions of Mozilla Firefox (x64 en-US) were listed (the latest 125.x and previous version, 124.x); Mozilla Maintenance Service was also left to the older version. This did not change after rebooting the PC.

Expected results:

All components of Firefox should have been updated, including Mozilla Maintenance Service. Running Firefox 125.0.1 installer standalone fixed all issues (without uninstalling in advance). You should consider adding a Repair option (in addition to Uninstall) to Firefox under Program and Features.

The Bugbug bot thinks this bug should belong to the 'Firefox::Installer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Installer
Component: Installer → Application Update
Product: Firefox → Toolkit
Version: Firefox 124 → unspecified
Version: unspecified → Firefox 124

Hi, thanks for the report! I believe that since you've reinstalled it's unlikely that any logs from this update are still left but can you please attach logs for the maintenance service and the updater binary regardless? You can find them in the locations detailed below:

Maintenance service: C:\Program Files (x86)\Mozilla Maintenance Service\logs\maintenanceservice.log
Updater binary logs:
1. Navigate to about:support
2. Find the "Update Folder" entry and click "Open Folder".
3. Open the updates directory.
4. Inside, you should find files named last-update.log and backup-update.log. Attach these files to this bug.

Severity: -- → S3
Flags: needinfo?(DGnani)
Attached file all-logs.zip

Adding last installation logs as instructed

Flags: needinfo?(DGnani)

(In reply to Nipun Shukla from comment #2)

Hi, thanks for the report! I believe that since you've reinstalled it's unlikely that any logs from this update are still left but can you please attach logs for the maintenance service and the updater binary regardless? You can find them in the locations detailed below:

Maintenance service: C:\Program Files (x86)\Mozilla Maintenance Service\logs\maintenanceservice.log
Updater binary logs:
1. Navigate to about:support
2. Find the "Update Folder" entry and click "Open Folder".
3. Open the updates directory.
4. Inside, you should find files named last-update.log and backup-update.log. Attach these files to this bug.

Just updated the report with the requested logs. This bug has been occurring fairly consistently for the last few months, if these logs did not capture the cause, we can probably capture the right logs at next update.

Additional details:

  • the presence under 'Program and Features' of the older Firefox version after in-app update seems machine specific (I have a laptop with similar software installed that does not have this issue)
  • the fact that Mozilla Maintenance Service does not get updated by the in-app update occurs on both systems (on my laptop after updating to 125.x Mozilla Maintenance Service was still at version 86.x)

I read into the logs a bit and what stands out to me is there's quite a few file access violations for C:\Program Files\Mozilla Firefox. I can't ascertain anything very useful from it though. Do you have anything irregular in how your system is set up? Specifically with respect to permissions around those directories.

The logs come from an office desktop, I have admin permissions but I did not install the OS myself and there are group policies in place. The only unusual permission on the directory you mention is a 'Read&Execute' permission assigned to a security account (S-1-15-xxxx). TrustedInstaller has 'FullControl'. There is a Crowdstrike antivirus running btw.

That said, the issue seems to affect only the in-app update but not the standalone update. I guess having the in-app update operate exactly as the standalone update would solve all issues i.e.

  • inability to update some files in C:\Program Files\Mozilla Firefox\ (happening only on a specific machine)
  • no update at all for C:\Program Files (x86)\Mozilla Maintenance Service (happening on all my PCs)

The logs make it clear that Firefox is running and causing the Maintenance Service to fail. Is this a multi-user machine, i.e., is some other OS-level user running Firefox and blocking updates in some way? Using the Task Manager to find Firefox instances would be helpful.

Flags: needinfo?(DGnani)

These are Windows 10 machines on Active Directory so remote and local admins can access for maintenance. That said, maintenance is mostly automated and, on the rare occasions they log onto the machines, they do not leave processes running behind. I have never seen another user's processes running in Task Manager while I am logged in. Still, the strange SID (S-1-15-3-1024-123xxx is not present anywhere in the registry) with Firefox execution permission makes me wonder.
In any case, besides the mechanics of how this happens, the simple tested solution is to have the in-app update work as the standalone update.

I have just tried updating from 125.0.1 to 125.0.2 and on both my work PCs (laptop and desktop):

  • Mozilla Maintenance Service is never updated (this seems not desirable)
  • Mozilla Firefox ended up updating w/o issues this time around
Flags: needinfo?(DGnani)

(In reply to DGnani from comment #9)

These are Windows 10 machines on Active Directory so remote and local admins can access for maintenance. That said, maintenance is mostly automated and, on the rare occasions they log onto the machines, they do not leave processes running behind. I have never seen another user's processes running in Task Manager while I am logged in.

I don't know what to tell you: the elevated logs make it clear that we can't write to firefox.exe, which almost always means a running process. We have witnessed issues that look like kernel-level locking bugs before, but who can say what's happening here.

Still, the strange SID (S-1-15-3-1024-123xxx is not present anywhere in the registry) with Firefox execution permission makes me wonder.

In any case, besides the mechanics of how this happens, the simple tested solution is to have the in-app update work as the standalone update.

These processes simply don't work the same way and don't have the same operating environments and assumptions. One reason, for example, that this is not straightforward is that the standalone update elevates as an Admin user where-as the in-app updater doesn't ask for elevation, it uses a SYSTEM service.

I have just tried updating from 125.0.1 to 125.0.2 and on both my work PCs (laptop and desktop):

  • Mozilla Maintenance Service is never updated (this seems not desirable)
  • Mozilla Firefox ended up updating w/o issues this time around

This was with the in-app updater, correct?

Flags: needinfo?(DGnani)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: