Closed Bug 1666324 Opened 4 years ago Closed 4 years ago

Thunderbird updates from 68 to 78 unexpectedly

Categories

(Thunderbird :: General, defect)

defect

Tracking

(thunderbird_esr68? fixed, thunderbird_esr78+ fixed, thunderbird82 fixed)

RESOLVED FIXED
83 Branch
Tracking Status
thunderbird_esr68 ? fixed
thunderbird_esr78 + fixed
thunderbird82 --- fixed

People

(Reporter: rjl, Assigned: rjl)

References

Details

Attachments

(2 files)

The issue of users getting updated from 68 to 78 unexpectedly keeps popping up. The update rules on Balrog are set such that for version 68.12.0, "manual" updates are enabled, (rate 0, fallback to no-update) Go to Help->About and get updated.

However, the Preferences tab going back to at least Thunderbird 68 includes aboutDialog-appUpdater.js and ends up sending the same request as if Help->About was opened.

https://searchfox.org/comm-central/source/mail/components/preferences/general.js#305-307

As long as updates are enabled, which is the default in our builds, the check is done. The response is handled in updateCheckListener.onCheckComplete:

https://searchfox.org/comm-central/rev/ecb867f734791071f843a6b0117c394cd0e3d720/mail/base/content/aboutDialog-appUpdater.js#332-339

if (updateAuto) will resolve to true in our builds by default, I believe the only way to change that is to disable updates by Policy. (app.update.auto is the pref, and it defaults to true)

This is called in general.js every time you open Preferences. There's no easy way for a user to stop an update once it's staged and staging will happen.

I propose rolling a 68.12.1 with a fix. Patch is coming.

Attached image image.png

Log from Thunderbird 68.12.

At 13:35:43 the background check happened. That worked as expected, no "force=1" in the URL.

At 13:45:05 I opened Preferences and immediately another update request got sent with force=1.

Sometimes we have the Balrog update rate set to 0 to allow for only "manual" updates.

However, when Help->About or Preferences is opened, an update check starts with force=1
which bypasses the 0 rate and downloads whatever update is available.
This causes numerous support requests and bugs from users saying they were updated
unexpectedly as there is no easy way to back out of an update once it has been
staged.

Both the About dialog and the Preferences tab use the same code from
aboutDialog-appUpdater.js to start the check and handle the result, so this change
displays the button giving the user the option to download. That code already
exists and works.

An update should not be forced by either checking your current version in About
or by opening Preferences.

(In reply to Rob Lemley [:rjl] from comment #2)

An update should not be forced by either checking your current version in About
or by opening Preferences.

+1

Thanks for discovering it. I wish it had been discovered earlier.

Assignee: nobody → rob
Status: NEW → ASSIGNED

This should backport to 68.12 pretty easily as that code is from 2006. I will run some try builds.

I did a try build with this applied to 68.12, though I have not had a chance to do any testing with it yet.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=98eaba087243cfc7a2f9d74e4fa8bf8a1b61ffaf

I am advocating for a 68.12.1 release with this patch applied as I believe it will help tremendously with the frequent issues reported by our users with unwanted updates.

Target Milestone: --- → 83 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ab66d318053c
Do not automatically download updates when opening About or Preferences. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

I don't understand why it would go on 68, which is end of life since yesterday. At this point all users of 68 must upgrade to 78.

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

I don't understand why it would go on 68, which is end of life since yesterday. At this point all users of 68 must upgrade to 78.

Because TB 78 has some known regressions (in particular for Enigmail users), and it would be good to give users a choice.

The update checker will still run and do the upgrade if there is one. Not with force=1, but once we have a rate > 0 that doesn't matter. We'll need to have that rate be > 0 real soon now, so at best you delay updating by 2-3 weeks.

Given that any updates still always have the even so small risk of causing problems for users in general due to anti-virus, and whatever, this doesn't seem like a good return. There's a non-zero risk for 30M users to potentially delay the upgrade by 2-3 weeks for around 75% of the 100k Enigmail users that did not yet upgrade.

I disagree. The reason for fixing this was to make the transition from 68 to 78 easier today. We can't even have updates on at rate 0 because the moment someone opens their Preferences they get force updated.

I think this an example where the customer POV is paramount.
a) Upgrading people that don't expected it or ask for it potentially puts them at real risk, or loss of productivity. We shouldn't do it, period.
b) We are blatantly not functioning as advertised, not to mention circumventing user choice

Things like this give us a poor reputation. And frankly I'm a little pissed that I told people things publicly that turned out not to be true. This is partly about restoring trust and our good name.

(In reply to Wayne Mery (:wsmwk) from comment #11)

a) Upgrading people that don't expected it or ask for it potentially puts them at real risk, or loss of productivity. We shouldn't do it, period.

Are you suggesting we should leave people on EOL'd versions (which 68 already is)?
If not, an upgrade can only play us some time. Very little time. None, if we're being pedantic since people should be on 78 already.

Everyone who wants security updates should go to 78.

But there might be people who prefer to be at risk and keep old functionality, while we're continuing fixing bugs.
If someone disables updates, we should respect their wish.

Please don't put words my mouth that I didn't say. I'm only saying make it function as it should have from the start.

Put your customer hat on please.

Furthermore, not being able to properly manage the user update rate puts US at risk of fighting fires, and of overwhelming support. (plus again the reputation thingy)

I would have loved to have everyone on version 78 a month or two ago. I don't like it that we are not there, I hate it. But it is TOTALLY unrealistic to have done so. Even now, today we have a topcrash with 78.3.0 and emergency stopped updates. You would suggest we should update users from 68 to 78 today? Every enigmail user on 78 today? or yesterday?

(In reply to Wayne Mery (:wsmwk) from comment #14)

I'm only saying make it function as it should have from the start.

All I'm saying is, it's too late. Just my opinion.
If you want to go ahead, sure.

(In reply to Kai Engert (:KaiE:) from comment #13)

If someone disables updates, we should respect their wish.

This change has nothing to do with disabled updates though. If updates are truly disabled, then they wouldn't get updated no matter what.

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

(In reply to Wayne Mery (:wsmwk) from comment #11)

a) Upgrading people that don't expected it or ask for it potentially puts them at real risk, or loss of productivity. We shouldn't do it, period.

Are you suggesting we should leave people on EOL'd versions (which 68 already is)?

We should not force the issue. Addon support is still a disaster and many popular addons (like compact header really) have not yet or will not be updated. Users what to get their work done. So yes, they want to stay on the version that works and does the job for them rather than the new secure one that does not. It is really that simple. I have felt like some form of leper for years because I try and voice what the users ask for, but they are not interested in going off to make coffee and coming back to their desktop locked up for 2 hours while thunderbird updates and disables what they consider to be essential addons. My experience with the leap from 68 to 78 took more than 2 hours on it's first attempt, was a complete failure and even after I got the thing limping it was a week before I actually had an address book or could send an email (damned good construction. No address book meant that the send failed. I hope the JS version is a little more understanding. I was trying to update to write some support articles, but in the end my writing time was spent trying to make the product work.

Comment on attachment 9176958 [details]
Bug 1666324 - Do not automatically download updates when opening About or Preferences.

[Approval Request Comment]
Discussed with wsmwk via Matrix to take this for 68.12.1.

Additionally requesting for 82 beta and 78.3.x.

End user impact if declined is that opening preferences downloads an update and stages it. This patch stops that and displays the "There's an update available" button which triggers existing code to download and stage the new version. The only time this becomes an issue is when we have updates between major versions set to 0 for manual updates.

Attachment #9176958 - Flags: approval-comm-esr78?
Attachment #9176958 - Flags: approval-comm-esr68+
Attachment #9176958 - Flags: approval-comm-beta?

Comment on attachment 9176958 [details]
Bug 1666324 - Do not automatically download updates when opening About or Preferences.

[Triage Comment]
Approved for esr78

Approved for beta

Attachment #9176958 - Flags: approval-comm-esr78?
Attachment #9176958 - Flags: approval-comm-esr78+
Attachment #9176958 - Flags: approval-comm-beta?
Attachment #9176958 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: