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

Status: RESOLVED FIXED

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

Description

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.

Comment 1

[John Bieling (:TbSync)]

Please ignore the trailing "I do not know" - I wish I could edit my own comments...

Comment 2

[WaltS48 [:walts48]]

(In reply to John Bieling (TbSync) from comment #1)

Please ignore the trailing "I do not know" - I wish I could edit my own comments...

You don't see the Pencil icon to the left of the Tag icon in your comments?

Comment 3

[John Bieling (:TbSync)]

No pencil icon. I posted a screenshot on IRC/maildev.

It looks like not everybody can edit comments.

Comment 4

[Jorg K (CEST = GMT+2)]

John, do you have editbugs privileges. If not, request them. Editing comments started working magically one day for me.

Comment 5

[Andrei Hajdukewycz [:sancus]]

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.

Comment 6

[John Bieling (:TbSync)]

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.

Comment 7

[Geoff Lankow (:darktrojan)]

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.

Comment 8

[Magnus Melin [:mkmelin]]

We may just want to relnote it.

Comment 10

[Jorg K (CEST = GMT+2)]

Release note coming up!

Comment 11

[Wayne Mery (:wsmwk)]

(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.

Comment 12

[Matt]

(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.

Comment 14

[Axel Grude]

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.

Comment 15

[Andrei Hajdukewycz [:sancus]]

(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/

Comment 17

[Geoff Lankow (:darktrojan)]

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.

Comment 18

[Geoff Lankow (:darktrojan)]

Attachment: 1574183-extensions-update-1.diff

Comment 19

[Magnus Melin [:mkmelin]]

Comment on attachment 9123235 [details] [diff] [review]
1574183-extensions-update-1.diff

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

LGTM, r=mkmelin

Comment 20

[Pulsebot]

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

Comment 21

[Jonathan Kamens]

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.

Comment 22

[John Bieling (:TbSync)]

@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.

Comment 23

[Jonathan Kamens]

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

Comment 24

[Magnus Melin [:mkmelin]]

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

Comment 25

[Wayne Mery (:wsmwk)]

Comment on attachment 9123235 [details] [diff] [review]
1574183-extensions-update-1.diff

Approved for ESR

Comment 26

[Axel Grude]

Great news! \o/

Comment 27

[Magnus Melin [:mkmelin]]

Thunderbird 68.7: https://hg.mozilla.org/releases/comm-esr68/rev/44021677b82453c064c05d5fb972dac7a756699d

Comment 28

[Axel Grude]

I am still getting users of Thunderbird 68.10.0 (the current ESR) being affected by this bug - what gives?