Closed Bug 1963993 Opened 1 year ago Closed 1 year ago

Thunderbird automatic updates fail: Version doesn’t change, “Restart to update Thunderbird” button doesn’t go away - Running Thunderbird v138.0 (issue began several updates ago)

Categories

(Thunderbird :: Installer, defect)

Product:
Thunderbird
Component:
Installer
Version:
Thunderbird 138
Type:
defect

Tracking

(thunderbird139+ affected)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
thunderbird139 + affected

People

(Reporter: joemcken64, Unassigned)

Details

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

Steps to reproduce:

When the About Thunderbird window says an update is available, I click the “Download update” button, and once it’s applied, I click the “Restart to update Thunderbird” button.

Actual results:

Thunderbird restarts, but the About Thunderbird window shows the old version is still installed, and the “Restart to update Thunderbird” button is still present. This persists indefinitely, no matter how many times the application is restarted.

Expected results:

Thunderbird should apply the update correctly and the “Restart to update Thunderbird” button should disappear immediately once the updated application launches.

Further information:

The only way to actually update is to run the Thunderbird installer, and even then, the “Restart to update Thunderbird” button still appears after the first launch. Only after clicking it and restarting Thunderbird a second time is the update finally applied.

I previously had this same issue on a different computer (my laptop) in the past; I eventually fixed it by deleting the “AppData\Local\Thunderbird” folder and restarting the app. However, it did not work this time; the issue manifested again at the next update.

I then (after backing up my user profile at “AppData\Roaming\Thunderbird\Profiles\<profile>.default”) completely uninstalled Thunderbird and deleted the Thunderbird folders in both AppData\Local and AppData\Roaming, and then reinstalled from scratch. After confirming the latest version was installed, I then imported my backed-up profile. This also did not work; the issue manifested again at the next update.

Running Thunderbird v138.0 (issue began several updates ago) on Windows 10 Pro (x64) v22h2.
The only extensions I have installed are “Dark Reader”, “ImportExportTools NG” and “Provider for Google Calendar”.

Component: Untriaged → Installer
Summary: Thunderbird automatic updates fail: Version doesn’t change, “Restart to update Thunderbird” button doesn’t go away → Thunderbird automatic updates fail: Version doesn’t change, “Restart to update Thunderbird” button doesn’t go away - Running Thunderbird v138.0 (issue began several updates ago)

This looks like bug 1941931 which should be fixed. Did it still occur when updated to 138.0?

(In reply to Corey Bryant from comment #1)

This looks like bug 1941931 which should be fixed. Did it still occur when updated to 138.0?

Yes, as far as I’m aware (would need an update available to test it) this still happens on v138.0.

If this occurred when updating from 137->138, can you add a comment to that bug specifying so?

(In reply to Corey Bryant from comment #3)

If this occurred when updating from 137->138, can you add a comment to that bug specifying so?

Sure. I explained in my OP that the issue has been occurring for the last few versions – maybe the last 4–5 updates or so – though I’m not sure which version exactly it appeared on. I’ll write down v137 for now.

(In reply to Corey Bryant from comment #3)

If this occurred when updating from 137->138, can you add a comment to that bug specifying so?

Correction: I will instead ask how I edit my bug report, as I can’t decipher this interface. The “Edit Bug” button displays a bunch of options and menus, none of which seem to let me edit my initial report. (That is what you meant by “add[ing] a comment” to it, right?)

(In reply to Corey Bryant from comment #3)

If this occurred when updating from 137->138, can you add a comment to that bug specifying so?

Sorry, please ignore the last two posts; got confused. That thread seems to be about a similar issue with Firefox; mine is with Thunderbird. Would the details of my Thunderbird issue really be relevant to that thread?

That code is (mostly) shared, so yes.

(In reply to Magnus Melin [:mkmelin] from comment #7)

That code is (mostly) shared, so yes.

Understood. I’ve posted the info there.

(In reply to joemcken64 from comment #5)

(In reply to Corey Bryant from comment #3)

If this occurred when updating from 137->138, can you add a comment to that bug specifying so?

Correction: I will instead ask how I edit my bug report, as I can’t decipher this interface. The “Edit Bug” button displays a bunch of options and menus, none of which seem to let me edit my initial report. (That is what you meant by “add[ing] a comment” to it, right?)

The pencil in the upper right of a description or comment box will allow you to edit.

(In reply to Corey Bryant from comment #9)

The pencil in the upper right of a description or comment box will allow you to edit.

This is only possible for people who have editbugs privileges, which is not the normal case for bug reporters.

(In reply to Corey Bryant from comment #1)

This looks like bug 1941931 which should be fixed. Did it still occur when updated to 138.0?

It does appear to be that bug; I had mentioned TB was affected somewhere in there and made @Wayne Mery aware of it.

I can confirm (by downgrading/updating) it's still not fixed in TB 138 or 139.

TB updated today from 139.0b1 to 139.0b2 in the normal fashion.

Just updated from v138.0 to v138.0.1. No change for me. Still had to run the installer manually and restart one extra time to get the update to work.

(In reply to joemcken64 from comment #13)

Just updated from v138.0 to v138.0.1. No change for me. Still had to run the installer manually and restart one extra time to get the update to work.

See my comment just above. Beta's working, so the next release version (around May 27) should be fixed.

🤞

Problem persists when updating from release 138 to 139.

Confirmed, issue persists with update to v139.0 here too.

+1

Question: When updating Thunderbird or Firefox, should there be a User Account Control prompt requesting to run the installer with administrator privileges? I’ve noticed that neither Firefox nor Thunderbird ask me for admin privileges when running their built-in automatic updater, but Thunderbird does ask me for admin privileges when I run the manual installer.

Just spitballing here, but is it possible this is some UAC/account privileges issue, and that when FF/TB are installed as an admin, they then require admin. privileges to update correctly? And therefore, if the automatic updater is run whilst the app is running without admin privileges (as it normally does on my end), the update fails?

Apologies if this is a basic query, but I’ve been wondering about this, so if someone could explain it, I would appreciate it.

Updating to v139.0.1 worked normally through the built-in updater just now. Didn’t have to run the installer manually.

(In reply to joemcken64 from comment #20)

Updating to v139.0.1 worked normally through the built-in updater just now. Didn’t have to run the installer manually.

Same here.

Status: UNCONFIRMED → NEW
status-thunderbird139: --- → affected
tracking-thunderbird139: --- → +
Ever confirmed: true

In my case, 139.0.1 > 139.0.2 took a few tries. TB kept getting stuck as a running process though it appeared to have shut down from the screen point of view. Wasn't until I did an End Task on the process itself and then started back up that it finally updated.

Just installed v139.0.2 from the built-in updater, and it worked without issue.

-> WFM then per comment 22 and comment 23.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.