1941931 - Firefox won't update on restart; it must be closed and then reopened

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Ed]

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

Steps to reproduce:

Clicked Help > About Firefox > clicked the update button > clicked the 'Restart to Update Firefox' > clicked Help > About Firefox.

Actual results:

The 'Restart to Update Firefox' button was still there. Clicking it and restarting that way always produces the same scenario.

Expected results:

After clicking the 'Restart to Update Firefox' button and restarting, Help > About Firefox should be showing that FF is up to date. Pretty sure this started with beta v133.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Ed]

Instead of restarting FF, closing/reopening produces the expected results.

Comment 3

[Max Christian Pohle [:/dev/max]]

Hey Ed, it would help a lot if you could enable update logging and try this again. To do this, go to about:config, search for app.update.log and set it to true. Then press Ctrl+Shift+j (or use the burger menu ☰ -> More Tools -> Browser Console) and watch what happens when you open the help dialog again and try to update. Please copy the log messages that start with AUS: from there to the clipboard and paste them here.

Comment 4

[Ed]

Attachment: console-export.txt - only beta is running

Comment 5

[Ed]

Attachment: console-export2.txt - beta and release are running

Comment 6

[Ed]

(In reply to Ed from comment #2)

Instead of restarting FF, closing/reopening produces the expected results.

Actually, the update only happens if I close/reopen beta while the release version is running.

I noted this in the logs:

When beta is the only version running:
Other instance of the application currently running: true

When beta and release are running:
Other instance of the application currently running: false

Don't know what to make of that!

Also of note: Thunderbird beta appears to have a variation of the same problem. Close/reopen works, but TB release doesn't need to be running.

Comment 7

[Eric Chen]

Looping in @bytesized for more insights

Comment 8

[Robin Steuber (she/her) [:bytesized]]

Download Process Explorer. When this problem happens:

1. Navigate the browser to about:support. Find the row that says "Update Folder" and take note of the directory name. Mine, for example, is 6F193CCC56814779.
2. Launch Process Explorer.
3. File -> Show Details for All Processes. Accept the resulting UAC prompt.
4. Find -> Find Handle or DLL.
5. Enter UpdateLock- and your update directory name. I would enter UpdateLock-6F193CCC56814779. Press Search and wait for the search to complete.
6. How many processes come up? If you click on each one, what arguments were they all invoked with?

Comment 9

[Ed]

what arguments were they all invoked with?

How do I find that, exactly? When I open the process, there are several tabs.

Comment 10

[Robin Steuber (she/her) [:bytesized]]

When you click on the process in step 6, it should highlight the row in the main UI, for which one of the columns should be "arguments"

Comment 11

[Ed]

Attachment: Process Explorer - only release running

Comment 12

[Ed]

Attachment: Process Explorer - only Nightly running

Comment 13

[Ed]

Attachment: Process Explorer - only Beta running

Comment 14

[Ed]

Attachment: Process Explorer - only Beta running_after_restart

Comment 15

[Robin Steuber (she/her) [:bytesized]]

What's the context here? Did you check that the problem was happening when you collected all of these?

Comment 16

[Ed]

Attachment: Process Explorer - only Beta running_after_close then reopen

Comment 17

[Ed]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #15)

What's the context here? Did you check that the problem was happening when you collected all of these?

The two beta ones were done after the update was downloaded and either restarted or closed >opened. The others were done before that just to see what it showed. Still won't update unless closed > reopened.

Comment 18

[Robin Steuber (she/her) [:bytesized]]

I feel like maybe I'm misunderstanding.

(In reply to Ed from comment #0)

Steps to reproduce:

Clicked Help > About Firefox > clicked the update button > clicked the 'Restart to Update Firefox' > clicked Help > About Firefox.

Actual results:

The 'Restart to Update Firefox' button was still there. Clicking it and restarting that way always produces the same scenario.

Can you please be more specific about what's happening? Just knowing that the button is still there isn't really enough. Does the browser restart? Does the window close? Does a window open? Does anything happen at all?

Comment 19

[Ed]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #18)

I feel like maybe I'm misunderstanding.

(In reply to Ed from comment #0)

Steps to reproduce:

Clicked Help > About Firefox > clicked the update button > clicked the 'Restart to Update Firefox' > clicked Help > About Firefox.

Actual results:

The 'Restart to Update Firefox' button was still there. Clicking it and restarting that way always produces the same scenario.

Can you please be more specific about what's happening? Just knowing that the button is still there isn't really enough. Does the browser restart? Does the window close? Does a window open? Does anything happen at all?

Sorry! Yes, the browser restarts after clicking the 'Restart to update' button. Then when I go back to Help > About, the 'Restart to update' button is still there. It is only after I close the browser > reopen it > go back to Help > About, that the 'Up to date button' shows.

Comment 21

[Thorin [:thorin]]

Can you please be more specific about what's happening?

See my duplicate issue. So to clarify, once the about firefox dialog button reports Restart to update Firefox, you click it, the browser window(s) close, and the browser "restarts" - go back into the about Firefox dialog and the Restart to update Firefox persists

OP mentioned something about beta or other releases being open. I just updated nightly no problems with stable and beta open. The issue, so far, seems to be limited to beta (portable FF) and dev (installed) and started this release cycle: both have the same update settings, Weird that nightly (installed, same update settings) doesn't suffer from this. Let's hope the issue doesn't ride the train to release.

Next beta update will be to 136.0 - I can't check any process handles until then

Comment 22

[Robin Steuber (she/her) [:bytesized]]

I can't really think of any more ideas for how to debug any further here without either being able to reproduce the situation myself (so I can debug it with an actual debugger) or making custom builds to have the reporter(s) use. I haven't been able to reproduce the situation. Unfortunately, I don't have time to make a custom build for this right now. So I'm going to redirect this back to the triage owner.

Comment 23

[Ed]

Workaround found:

• install v133.0b9 from https://archive.mozilla.org/pub/firefox/candidates/133.0b9-candidates/

• to preserve your existing profile, do not start FF via the install script

• go to your beta profile folder and delete the compatibility.ini file

• start FF

• if you're not prompted to update immediately, go to FF menu > Help > About FF

Comment 24

[Ed]

Need a new workaround because today's update failed again until close > restart.

Comment 25

[Thorin [:thorin]]

Attachment: betaupdate.png

active-update.xml

<?xml version="1.0"?><updates xmlns="http://www.mozilla.org/2005/app-update"><update xmlns="http://www.mozilla.org/2005/app-update" appVersion="135.0" buildID="20250127201358" channel="beta" detailsURL="https://www.mozilla.org/en-US/firefox/135.0/releasenotes/" displayVersion="135.0" platformVersion="undefined" installDate="1738107977372" isCompleteUpdate="false" name="Firefox 135.0" previousAppVersion="135.0" promptWaitTime="691200" serviceURL="https://aus5.mozilla.org/update/6/Firefox/135.0/20250124091819/WINNT_x86_64-msvc-x64/en-US/beta/Windows_NT%252010.0.0.0.26100.2605%2520(x64)/ISET%3ASSE4_2%2CMEM%3A32617/default/default/update.xml?force=1" type="minor" statusText="Install Pending" foregroundDownload="true"><patch size="76814782" type="complete" URL="https://download.mozilla.org/?product=firefox-135.0build1-complete&amp;os=win64&amp;lang=en-US" hashFunction="sha512" hashValue="e0be1183f13245a558dbc338617a8c1a2638c27dda01a21b2a84fd65774ed474f621f42543d5386233c1a1188e045879ed9149791ee238827e26bf18908f9d76"/><patch size="11119591" type="partial" URL="https://download.mozilla.org/?product=firefox-135.0build1-partial-135.0b9build1&amp;os=win64&amp;lang=en-US" selected="true" state="pending" hashFunction="sha512" hashValue="1a615522f25c057deb1c8de8e5dcd58f1018f6d1430f1258af0b4a831302971256b82bd24d5f634a66aec4eb355fc875811ceac9556f0c00c1fc9cb7bfd1e3d7" bitsId="{722C3AA0-4D79-46D3-9A16-2B20BC844E31}" bitsResult="0"/></update></updates>

How many processes come up? If you click on each one, what arguments were they all invoked with?

1 process, there is no column available (checked columns for display settings) anywhere for arguments - did you mean command line? The corresponding 7260 PID highlighted by the search shows the firefox.exe has no command lines whatsoever

Comment 26

[Ed]

Attachment: console-export-after clicking Help_About_FF button.txt

Comment 27

[Ed]

Attachment: console-export-after clicking restart button.txt

Comment 28

[Ed]

Attachment: console-export-after close_reopen.txt

Comment 29

[Ed]

I added three log files which might make the sequence of things more clear.

I noticed this in the second log; only beta was running then:

AUS:SVC Other instance of the application currently running: true

After closing/restarting, the value changed to false.

Comment 30

[Chris DuPuis]

Hi Ed, can you open the about:config page and see what value is currently set for this key: app.update.service.enabled

(Apologies, I originally gave the wrong key. The key I'm looking for is app.update.service.enabled)

Comment 31

[Thorin [:thorin]]

app.update.service.enable: FYI: I just tested nightly with the pref at false and had no issue. Will test Beta/Dev next time they have an update available with the pref at true

releases = {
	stable134: {
		pref: false, issue: 'no'
	}
	beta135: {
		pref: false, issue: 'yes'
	}
	dev135: {
		pref: false, issue: 'yes'
	}
	nightly136: {
		pref: true, issue: 'no'
	}
	nightly136test: {
		pref: false, issue: 'no'
	}
}

Comment 32

[Ed]

(In reply to Chris DuPuis from comment #30)

Hi Ed, can you open the about:config page and see what value is currently set for this key: app.update.service.enabled

(Apologies, I originally gave the wrong key. The key I'm looking for is app.update.service.enabled)

It is false on beta, as well as release and nightly. I have always disabled the Mozilla Maintenance Service and never automatically install updates, if that matters. There has not been this problem with release or nightly, but it also affects Thunderbird beta.

Comment 33

[Ed]

Problem persists on the update to 136.0b1.

Comment 34

[Robin Steuber (she/her) [:bytesized]]

Does the problem stop if you use about:config to set app.update.multiSessionInstallLockout.enabled to false?

Comment 35

[Ed]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #34)

Does the problem stop if you use about:config to set app.update.multiSessionInstallLockout.enabled to false?

Yes!

Comment 36

[Robin Steuber (she/her) [:bytesized]]

Yeah, I'm fairly confident the problem here is that when Firefox restarts to update, it sometimes detects the previous instance that is still shutting down. I think that the solutions here are either (a) delete the lock file when the "Restart" button is clicked, or (b) let go of the lock itself earlier in shutdown. I'm leaning towards option (b).

I'll see if I can whip up a quick patch for this after my current work is done.

Comment 37

[Thorin [:thorin]]

https://old.reddit.com/r/firefox/comments/1iruaqb/136_beta_update_issue/

Comment 38

[Ed]

https://www.reddit.com/r/firefox/comments/1isvp0v/update_v13501_error_restart_to_update_goes_back/

Comment 39

[Robin Steuber (she/her) [:bytesized]]

Attachment: Bug 1941931 - Release the Multi Instance Lock earlier in shutdown r=nrishel!

Comment 40

[Robin Steuber (she/her) [:bytesized]]

I'm about ready to merge this patch, but I'm going to set this but to leave-open first. Logically, I think it is very likely that this patch will fix this bug. But I can't reproduce the problem, so it's hard to be totally sure. I don't want to close this bug until we can get some feedback that this was, in fact, the right fix.

Comment 43

[Donal Meehan [:dmeehan]]

:bytesized, I've seen a few reports of users having issues with updates applying in release (a few mentions on reddit)
It looks like this is good to land, so hopefully it might get a beta uplift at least for Fx137?
It's not tracked as a regression but I've only seen reports recently. Do you know what might have introduced it?

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12f8c6bbd677
Release the Multi Instance Lock earlier in shutdown r=nrishel

Comment 45

[Robin Steuber (she/her) [:bytesized]]

(In reply to Donal Meehan [:dmeehan] from comment #43)

:bytesized, I've seen a few reports of users having issues with updates applying in release (a few mentions on reddit)
It looks like this is good to land, so hopefully it might get a beta uplift at least for Fx137?

As long as this actually fixes the problems, that's the plan.

It's not tracked as a regression but I've only seen reports recently. Do you know what might have introduced it?

Bug 1907124. I guess I never set this in the bug. I was never really able to find get proof that that was what's going on. But the explanation fits the facts quite well, so that's my assumption.

Comment 46

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/12f8c6bbd677

Comment 47

[BugBot [:suhaib / :marco]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 48

[Heribert Slama]

I ran into this problem when updating from release 135.0.1 (not a beta) to 136.0. Restart to update closed and re-opened the browser, but it remained at 135.0.1 - repeatedly. Even a system restart didn't help. But it gave me an idea: I **unchecked ** the setting "Open Firefox automatically when your computer starts up", restarted Windows, opened Firefox and the update was completed!

Comment 49

[Robin Steuber (she/her) [:bytesized]]

I am really hoping that this patch fixes the problem. But I still have not been able to reproduce the problem. Can someone that does experience this problem try out this version of Nightly and see if the problem still occurs?

Comment 50

[Ed]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #49)

I am really hoping that this patch fixes the problem. But I still have not been able to reproduce the problem. Can someone that does experience this problem try out this version of Nightly and see if the problem still occurs?

Not really sure how to test, as the problem isn't in Nightly - only Beta.

Comment 51

[Robin Steuber (she/her) [:bytesized]]

(In reply to Ed from comment #50)

Not really sure how to test, as the problem isn't in Nightly - only Beta.

Wait. Is it a problem with Beta or a problem with your profile? Can you reproduce this problem in Beta with a fresh profile? You can make one in about:profiles.

Comment 52

[Ed]

It's a Beta problem which one other commenter here has and several others on Reddit:

https://www.reddit.com/r/firefox/comments/1iruaqb/136_beta_update_issue/

https://www.reddit.com/r/firefox/comments/1ix5j08/stable_build_135_cannot_update_to_13501_using/

https://www.reddit.com/r/firefox/comments/1j3rxfk/13501_restart_to_update_bug_doesnt_change_to_136/

I suspect there are more that don't even know about the problem, because they don't close their browsers often.

I'll try a new profile, but likely not until Wednesday.

Comment 53

[Robin Steuber (she/her) [:bytesized]]

Oh, shoot. I know exactly why this isn't reproducing on Nightly. Because app.update.multiSessionInstallLockout.timeoutMs is 0 on Nightly. I bet that setting that to be larger would cause the error to reproduce there (note that doing this causes a known bug: you may see "Restart to Update" buttons where clicking them results in a restart with no update).

Comment 54

[Ed]

BTW, I noted above that the problem also exists in Thunderbird beta. I've notified the appropriate TB personnel.

Comment 55

[Ed]

Robin: "I bet that setting that to be larger would cause the error to reproduce there "

I set app.update.multiSessionInstallLockout.timeoutMs to 13579 and it did reproduce the problem.

Comment 56

[Ed]

In Beta, I set app.update.multiSessionInstallLockout.timeoutMs to 0 and it fixed the problem.

Comment 57

[Ed]

New complaint: https://www.reddit.com/r/firefox/comments/1ja13ud/ff_13601_keeps_telling_me_to_restart_to_update/.

Comment 58

[Robin Steuber (she/her) [:bytesized]]

I continue to not be able to reproduce this. On Beta or on Nightly with app.update.multiSessionInstallLockout.timeoutMs set to a large value (I've been using 60000000, which is 1000 minutes). I tried on a completely fresh VM and couldn't reproduce it there either. I've been trying this build of Nightly and this build of Beta. These should both be from prior to 2025-03-05, when I merged the patch that (hopefully) fixed it. So I assume there is some difference is between my configuration everyone else's here. But I still have no idea what.

(In reply to Ed from comment #55)

I set app.update.multiSessionInstallLockout.timeoutMs to 13579 and it did reproduce the problem.

You could reproduce this problem on Nightly? Are you able to reproduce it when trying to update from this version? Are you still able to reproduce it when installing from this version? If so, we can probably call this fixed and uplift this patch. If not... I'm not sure. Clearly we will have to figure something out.

Comment 59

[Ed]

Using app.update.multiSessionInstallLockout.timeoutMs = 60000000:

https://archive.mozilla.org/pub/firefox/nightly/2025/03/2025-03-01-09-17-11-mozilla-central/ - update problem was reproduced

https://archive.mozilla.org/pub/firefox/nightly/2025/03/2025-03-10-09-44-22-mozilla-central/ - no problem, updated as expected

Comment 60

[Robin Steuber (she/her) [:bytesized]]

Excellent! Then let's uplift this to Beta and call it fixed!

Comment 61

[Robin Steuber (she/her) [:bytesized]]

Comment on attachment 9468148 [details]
Bug 1941931 - Release the Multi Instance Lock earlier in shutdown r=nrishel!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Users that attempt to restart to update may not have the update actually be installed.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: If QA can reproduce the problem, that would be great. But I was never able to.
  STR:
  Allow an update to download. Click the "Restart to Update" button. Check about:support's Update History Button.
  Expected Results:
  An update is in the update history
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very small change to existing code path. Seems to fix the problem.
• String changes made/needed: None
• Is Android affected?: No

Comment 62

[Pascal Chevrel (relman team) -> :pascalc]

Comment on attachment 9468148 [details]
Bug 1941931 - Release the Multi Instance Lock earlier in shutdown r=nrishel!

Approved for beta 7 as one of the Reddit threads indicates that it happens for a dot release, so not limited to betas. Thanks.

Comment 63

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/7c7c43caef7e

Comment 65

[Giorgia Nichita, Release Desktop QA]

I was able to reproduce this issue yesterday when attempting to update from 137.0b6 to 137.0b7 on Windows 10. The update process did not complete as expected, and the "Restart to Update Firefox" button remained visible after restarting.

Today, I performed further testing on Windows 10, Ubuntu 22, and macOS 11 using the same steps. Additionally, I explicitly set app.update.multiSessionInstallLockout.timeoutMs = 60000000 on both Beta 137 and Nightly 138 to check for any persistent issues. However, I was no longer able to reproduce the problem, updates now complete as expected and Firefox correctly reflects the updated version after restarting.

Given that the issue no longer occurs across multiple platforms and configurations, I am marking this as Verified Fixed.

Comment 66

[Thorin [:thorin]]

not fixed IIUIC

I have not changed my beta or dev settings since I first reported it (in a duplicate bug). Updated to 137.0b7 several days ago and had to close FF and restart manually for it to apply. So far so good, expected since the patch was added to 137.0b7

Today I updated from 137.0b7 to 137.0b8 and the problem persists

edit: 345600000 is the pref value set by FF

Comment 67

[Ed]

Same here; problem persists.

app.update.multiSessionInstallLockout.enabled true
app.update.multiSessionInstallLockout.timeoutMs 345600000

I also downgraded and tried again with app.update.multiSessionInstallLockout.timeoutMs 60000000, which also did not work.

Comment 70

[Eric Chen]

This is happening on Firefox 136 release channel too

Comment 71

[aafn]

Hello, I have this bug since a few releases (can't tell exactly when it started, maybe with FF 131 or 132).
I had it today again when upgrading from 136.0.2 to 136.0.3.

The only way to exit the "loop" is to close Firefox, then start it again by hand after a few seconds to make sure (and after the first "Restart to upgrade" of course, or any other one later in the loop). Then the proper version will show up.

So I will be able to confirm when the problem disappears for me, if you believe that you have a fix for it.

Comment 74

[wheeheee]

Still have the same problem for 138.0b1 -> 138.0b2.

Comment 75

[Adi]

I have am also randomly having the same problem for a few months now, on multiple computers.

Using:
Mozilla Firefox - currently at v137.0;
Mozilla Thunderbird - stable version, currently at v137.0 - 10 minutes ago this one wanted to update to 137.0.1 but pressing the 'restart to update' button in the about window had no effect, so i had to stop and start it again
Mozilla Firefox Developer - currently at v138.0b2 - updated to 138.0b3 (by stopping and restarting the app)

Thunderbird 137 is not the only one doing this, i migrated from Thunderbird ESR 128 about 2 weeks ago - that was also doing it randomly. Also Firefox Developer and Firefox (standard one) are doing it sometime.

I think there might be some interaction with the User Account Control setting in Windows - i have set UAC to maximum level on all my systems and sometimes the Mozilla Updater shows an UAC elevation prompt - the Mozilla Maintenance Service is set to Manual start (i think this is the default setting? - i do not remember changing it).

Comment 80

[Mathew Hodson]

Marking bug 1907127 as the regressing bug since "app.update.multiSessionInstallLockout.enabled" was introduced there and reports indicate disabling that pref avoids the issue.

Comment 81

[Robin Steuber (she/her) [:bytesized]]

Let me give a quick update on this. I'm currently working on disabling the feature entirely for now (Bug 1959492). Across all update channels.

I have a few other small things on my plate before I can get back to this, but then I guess I will try option (a) from Comment 36.

(In reply to Robin Steuber (she/her) [:bytesized] from comment #36)

I think that the solutions here are either (a) delete the lock file when the "Restart" button is clicked, or (b) let go of the lock itself earlier in shutdown. I'm leaning towards option (b).

I sure hope that fixes it, because if it doesn't I'm gonna be really stumped as to what's causing this problem.

I'll try to get a patch up next week, then I am hoping that I can get some of the people here to test it. Then if timing allows, I want to uplift it to beta. Otherwise, we can just wait for it to ride the train to beta. And then I want to try to get some people here to test it on beta, where it seems to reproduce more consistently.

If the above does not work (and we still don't know why), we basically are left with two choices:

1. Revert this feature's functionality to the old functionality (pre-Bug 1907124), or
2. Spend a few days making a custom build with tons and tons of extra logging, hope that someone that can reproduce this will be interested in running it and giving us the logs, and then hope that those logs point us in the direction of the actual fix without more custom builds with more logging.

We have not yet decided which of those we would prefer to pursue in that case.

I'm sorry this has been such a nightmare, y'all. I really thought we had it fixed before I went on vacation, and... it's a long story. Obviously we dropped the ball, since this made it to Release.

Comment 82

[Dan]

Still happening. Have to shut down browser and restart for update to apply.

Comment 83

[Robin Steuber (she/her) [:bytesized]]

Hopefully that should be the last time. Possibly, depending on the exact version you are on, there could be one more before you get the update that turns the feature off.

Comment 86

[Daniel Veditz [:dveditz]]

Still happening.

The fix Robin mentioned in comment 81 shipped in Firefox 137.0.2 (this morning!) and 138.0b7 (yesterday). Update-related fixes often mean you need to update TO the fixed version before updates work correctly the next time you update.

Comment 89

[Ed]

Congrats! It's fixed for me today on Beta 138.0b9.

Comment 90

[Robin Steuber (she/her) [:bytesized]]

Attachment: Backed out changeset 12f8c6bbd677 (Bug 1941931) r=nrishel!

Comment 91

[Phabricator Automation]

Comment on attachment 9480366 [details]
Backed out changeset 12f8c6bbd677 (Bug 1941931) r=nrishel!

Revision D246290 was moved to bug 1960981. Setting attachment 9480366 [details] to obsolete.

Comment 92

[aafn]

Upgrade from 137.0.2 to 138.0 went well yesterday for me => bug corrected on my side.

Comment 93

[cycleforme]

Upgrade from 137.0.2 to 138.0 didn't fix the bug on my side

Comment 94

[bill lalonde]

When I try to update from 137.0.2 to 138.0, I no longer get the option to update if another instance is running.
I get "Firefox is being updated in another instance" which is not true and the download does not happen.
I expect that if I shut down the other instance, the update will proceed.

Comment 95

[:User5]

When I tried to update from 137.0.2 to 138.0, I also got "Firefox is being updated in another instance" and the Check for Updates button was "grayed". A workaround is to simply refresh the "Settings" page (or do any other actual web browsing.) This makes the Check for Updates button available.

Then, when I clicked Check for Updates, Firefox did the download and showed the "Restart to update Firefox" button. When I clicked that, the UAC dialog box showed. When I said OK, the Firefox Updater showed an install progress window and reloaded Firefox with a page that described new features (Tab groups...)

So, better than it was but not the way it works on ver 115.23 (Win7).

On another Win10 computer with identical software, Firefox did display "An update is available" (green dot near the hamburger menu) and the button on the Settings page worked as expected (download, UAC dialog, install) so this problem may only show itself for manual checks for updates.

Comment 96

[joemcken64]

Heya, I have a similar issue with Thunderbird, where the last few updates failed to install normally and the “Restart to update Thunderbird” button refuses to go away. I’ve had to update by running the installer manually. I was asked to mention here that I still experienced this issue whilst updating from Thunderbird v137.x to v138.0.

Comment 97

[joemcken64]

Edit: Forgot to link to my issue, bug 1963993. (Someone please add comment-editing to this site …)

Comment 98

[Ed]

(In reply to joemcken64 from comment #96)

I’ve had to update by running the installer manually.

Simply closing and re-opening TB should work.

Comment 99

[joemcken64]

(In reply to Ed from comment #98)

(In reply to joemcken64 from comment #96)

I’ve had to update by running the installer manually.

Simply closing and re-opening TB should work.

It should, but it certainly doesn’t for me. Tried closing and re-opening TB, tried the “Restart to …” button a hundred times, tried a PC reboot, tried deleting the “AppData\Local\Thunderbird” folder, even tried completely uninstalling & reinstalling TB – nothing works, the issue invariably reappears at the next update. Running the (latest) installer is the only thing that successfully updates TB, and even then, the “Restart to update …” button still reappears after the first launch, though it finally goes away after I click it one final time.

Comment 100

[Robin Steuber (she/her) [:bytesized]]

Then that sounds like a different problem. Please file a new bug instead of reusing this one.

Comment 101

[joemcken64]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #100)

Then that sounds like a different problem. Please file a new bug instead of reusing this one.

I did. Someone there asked me to comment on this one.

Comment 102

[Ed]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #100)

Then that sounds like a different problem. Please file a new bug instead of reusing this one.

Comment 97.

Comment 103

[BugBot [:suhaib / :marco]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:bytesized, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 104

[Robin Steuber (she/her) [:bytesized]]

I am calling this fixed by having backed out the feature causing the problem. I know there were some problems getting updated to the fixed version, but those should be past now. If anyone is still experiencing this issue with an up-to-date Firefox, please let me know.