Closed Bug 1574183 Opened 1 year ago Closed 6 days ago

Add-Ons are not automatically updated to newer (compatible) version after Upgrade TB60 -> TB68

Categories

(Thunderbird :: Add-Ons: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 74.0

People

(Reporter: john.bieling, Assigned: darktrojan)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

Steps to reproduce:

I updated from TB60 to TB68 RC2 and used my standard profile.

Actual results:

After first start of TB68, all addons are marked not compatible.

Expected results:

TB68 should have checked ATN and download the new compatible version of my addons. Or at least bring up a notification.

Sancus mentioned, that we did have such an upgrade notification. But it is not happening with TB68 RC2.

Currently I have to manually search for updates. But I guess not everybody knows how to do that.

Depends on: tb68found
Blocks: tb68found
No longer depends on: tb68found
Component: Untriaged → Add-Ons: General

OK, so I thought there was some kind of window that appeared warning you about incompatible add-ons on first run, but there doesn't appear to me. Maybe I'm imagining things, or maybe that was something that only existed many versions ago.

In any case, what DOES happen when you upgrade 52 -> 60 is that incompatible add-ons are immediately updated in the background to the newest compatible version. So, the function that is normally triggered by extensions.update.interval is triggered immediately on first run.

If this no longer happens in 68, I think that is the bug.

Flags: needinfo?(sancus)

Sancus asked me to verify, if the update check for addons will eventually update the addons or not.

I created a new profile in TB60 and upgraded that again to TB68 and after the first start I changed extensions.update.interval to 20s, restarted and shortly after the addons updated.

So it is really just a timing thing. From the user point of view, the first thing we do after upgrading Thunderbird is to check which addons work - and currently we get a list where every single addon (expect lightning) is marked as not compatible.

If it is a simple fix, I would suggest to enforce an addon update request while doing the profile upgrade.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Looks like updating add-ons at app update was killed off in bug 1433574.

The best replacement I've thought of is replicating this code at some point. But it's not a great option, frankly.

Flags: needinfo?(geoff)

We may just want to relnote it.

Keywords: regression
Duplicate of this bug: 1593035

Release note coming up!

(In reply to Jorg K (GMT+2) from comment #10)

Release note coming up!

Thanks! We've been seeing reports of this in support. Too bad we couldn't keep bug 1433574 - it's very bad UX.

Priority: -- → P2

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

(In reply to Jorg K (GMT+2) from comment #10)

Release note coming up!

Thanks! We've been seeing reports of this in support. Too bad we couldn't keep bug 1433574 - it's very bad UX.

It is bad UX, but having a warning without a stop now option makes having a warning somewhat pointless anyway.

Having all addon disabled on first start after update would have been a blocker I would have thought, I expect user discontent will be huge. The reality is few read release notes, but they sure know how to complain when thing do not meet their expectations. While I have been dealing with the items in support as wait for update, check for update I really have no desire to repeat that 5000 times.

Duplicate of this bug: 1593035

Just an update - after the holidays I checked my Add-on user numbers and lost about 30% (16,000 users) between three updates. Here are the stats:

SmartTemplate4: https://i.imgur.com/lEjjg4V.png
QuickFolders: https://i.imgur.com/JoW2y6Y.png
quickFilters: https://i.imgur.com/rI6OWPL.png

You can see a relationship with the Tb 68 transition: 60 goes down, 68 goes up - but only for the users who are either not affected by the bug or do a manual reinstall (right-clicking in extensions manager and check for updates is broken too). I am still hoping that people haven't uninstalled my Add-ons and only the update ping is missing, but I fear the longer this is unfixed the more genuine users I will lose.

https://i.imgur.com/zdLKOVy.png

both lines (60.9 vs 68) should have crossed over before new year. Interestingly both seem to oscillate "In sync" so it could also point to outages in the update servers? It's a little hard to analyse but I can make country specific investigations if needed.

(In reply to Axel Grude from comment #14)

Just an update - after the holidays I checked my Add-on user numbers and lost about 30% (16,000 users) between three updates. Here are the stats:

Every year I have to remind people that you can't say anything meaningful based on stats in December, because there's always a Christmas slump and it doesn't end until the 6th or 7th of January. Always look at overall TB stats before you come to any conclusions. https://stats.thunderbird.net/

Duplicate of this bug: 1607768

I have done some investigation on what is required here. We can reinstate the start-up check but it's a question of when we do it. It used to block the application starting and open a message if it was taking too long. This would hard to reproduce now. Given that extensions will all be restartless soon I think the update check can happen shortly after the application starts. Note that it has to happen on the first run after upgrading because it uses a list of extensions that were disabled by the upgrading.

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #9123235 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9123235 [details] [diff] [review]
1574183-extensions-update-1.diff

Review of attachment 9123235 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, r=mkmelin
Attachment #9123235 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → Thunderbird 74.0

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/71a037b9e9cd
At start-up, check for newer versions of extensions disabled by application update. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED

I hope we can get this into TB68. I would rather not spend another 6+ months explaining to my users why some of my add-ons stopped working when TB upgraded to 68.

@Geoff: Thanks for the work you put into fixing this. Very much appreciated!

As Jonathan has pointed out, this is really causing us lots of email traffic and bad reviews. I have multiple "WTF" emails per day (even though I do not understand the attitude of some user demanding stuff for free). If this is an easy backport, I would love to see it in TB68 as well, so future upgraders have a smoother UX.

Reopening to ask again for this to be backported to TB68. I still get questions resulting from this bug on a daily basis.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Status is for trunk. For 68, set an approval flag.

Status: REOPENED → RESOLVED
Closed: 1 month ago6 days ago
Resolution: --- → FIXED
Attachment #9123235 - Flags: approval-comm-esr68?
You need to log in before you can comment on or make changes to this bug.