1451097 - make add-ons incompatible/not compatible by default for tb60 and beyond

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: General, enhancement)

Description

[Magnus Melin [:mkmelin]]

For background:  https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible

Due to the amount of changes, it doesn't make sense for add-ons to be compatible anymore. If the add-on hasn't been updated, it's highly unlikely it would work correctly. 

I think we want to save people from bustage due to add-on incompatibilities.

Comment 1

[Magnus Melin [:mkmelin]]

Attachment: bug1451097_addon_incompatible_default.patch

This should do it.

Comment 2

[Jorg K (CEST = GMT+2)]

Comment on attachment 8964671 [details] [diff] [review]
bug1451097_addon_incompatible_default.patch

Excellent!

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/722576b33822
make add-ons in-compatible by default for TB 60 and beyond. r=jorgk

Comment 4

[Jorg K (CEST = GMT+2)]

Beta (TB 60 beta 2):
https://hg.mozilla.org/releases/comm-beta/rev/dc12a66492b3be009ed136a084a1129c3ab5aed5

Comment 5

[Jorg K (CEST = GMT+2)]

That killed Mozmill testing on beta :-(

Comment 6

[Jorg K (CEST = GMT+2)]

Attachment: 1451097-follow-up.patch

Comment 7

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-beta/rev/2ee8d27041d244a7da5710d94a99a58713a79947
Follow-up: Lift Mozmill and JS Bridge maxVersion to 60. rs=bustage-fix

Lifted the versions to 60 for now, but we need to find a better solution to this.

Comment 8

[Magnus Melin [:mkmelin]]

We probably just want to put some very large version number in there so we never have to touch it.

Comment 9

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-beta/rev/2748f1e02085a2f3a9ad21ebbb96cd03f0140c02
Backed out changeset 2ee8d27041d2. a=backout
https://hg.mozilla.org/releases/comm-beta/rev/0a74a8f08830d550cdd65895f69b26aa2db4bc69
Follow-up: Lift maxVersion for Mozmill, JS Bridge and test add-ons to *. rs=bustage-fix a=jorgk

There were still test failures since some test add-ons also had a fixed expiry version. Now I lifted these to * to avoid further problems. Note that mail/test/mozmill/folder-tree-modes/test-extension\install.rdf was already at *.

I'll update C-C accordingly if this run is a success.

Comment 10

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #8)
> We probably just want to put some very large version number in there so we
> never have to touch it.
Looks like someone else also wasn't aware that * is an option ;-)

Comment 11

[Jorg K (CEST = GMT+2)]

https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Extension_Versioning,_Update_and_Compatibility

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/60307cfe14dd
Follow-up: Lift maxVersion for Mozmill, JS Bridge and test add-ons to *. rs=bustage-fix

Comment 13

[Magnus Melin [:mkmelin]]

Comment on attachment 8964725 [details] [diff] [review]
1451097-follow-up.patch

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

Yeah I guess this is fine. r=mkmelin

::: mail/app/profile/all-thunderbird.js
@@ -125,5 @@
>  
>  // Controls enabling of the extension system logging (can reduce performance)
>  pref("extensions.logging.enabled", false);
>  
> -// Strict compatibility makes addons in-compatible by default.

I would keep this comment before the ifndef block, and not comment separately for release or not. It's just describing what pref does.

But do fix the misspelling (no hypen in incompatible)

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/de5ce5f50db7
Follow-up: No strict add-on checking on Daily. r=mkmelin

Comment 15

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-beta/rev/8bb1c4fd90ca87e81c0757b00dff5d49b734742a

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

I really think we shouldn't be doing this in the middle of the beta phase, without communication to all affected add-on developers. I can see why it makes sense, but users will have their incompatible add-ons disabled and be unhappy, and developers might not know they need to make any changes and be unhappy. It also means a slew of reviews for Thunderbird add-ons coming in last minute, and we can't promise quick reviews of legacy add-ons.

The least we can do is send out a message to all affected add-on developers. I would appreciate if someone could prepare a message that contains all necessary details, best to orient on one of the past compatibility report emails.

Comment 17

[Magnus Melin [:mkmelin]]

(In reply to Philipp Kewisch [:Fallen]  from comment #16)
> makes sense, but users will have their incompatible add-ons disabled and be
> unhappy, and developers might not know they need to make any changes and be
> unhappy.

Well they can't have it both ways. Without an update to the add-on chances it would still be compatible are quite slim. A broken add-on makes everybody unhappy. For the average user it might mean they have to abandon Thunderbird completely since that brokenness makes it not work at all. 

> The least we can do is send out a message to all affected add-on developers.
> I would appreciate if someone could prepare a message that contains all
> necessary details, best to orient on one of the past compatibility report
> emails.

I thought we didn't send any of those anymore, since a long time ago. Do you have one handy somewhere? The main thing would be to link them to https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57

Comment 18

[Jorg K (CEST = GMT+2)]

We had quite a few malfunctions caused by add-ons in TB 52 already, so making add-ons incompatible by default is the way to go for TB 60, and if we don't do it in the middle of the beta phase, there will never be a good time to do it.

A agree that this will cause a lot of churn on AMO, I uploaded three new versions last night, always with the clause "No change, just updated compatibility to Thunderbird 60". Sadly I didn't see a "Just update compatibility" button.

As for getting in touch with TB add-on developers (like we did for the hiring) is a good idea. I've seen the compatibility reports in the past, but don't have one at hand. I'm not sure it would be useful since it just said, IIRC, "you add-on has been automatically testes and is deemed compatible". We're now doing quite the opposite: We're not testing anything, instead we declare everything incompatible. That said, if you can get me the text, I'll see whether I can reuse bits of it. I'm going to write something up later today. Is there perhaps a comment the developer could place into the "reviewers hints" that could minimise the workload and fast-track re-approvals?

Comment 19

[Philipp Kewisch [:Fallen][📱📆]]

I'm rather aiming for the one that says ~"your add-on needs changes", not "you add-on has been automatically testes and is deemed compatible". I'm sure we can extract that from AMO somewhere.

You can change the compatibility info on the versions page of an add-on, there is no need to upload a new version just to change the compatibility.

Comment 20

[Wayne Mery (:wsmwk)]

> For the average user it might mean they have to abandon Thunderbird completely since that brokenness makes it not work at all. 

Our extremely high ADI numbers for recent betas (~70k) which appear to be stable should mean we do not have a high percentage of users abandoning betas because of add-ons (thankfully) - rather it seems likely to be very low impact.


> I really think we shouldn't be doing this in the middle of the beta phase, without communication to all affected add-on developers. I can see why it makes sense, but users will have their incompatible add-ons disabled and be unhappy, and developers might not know they need to make any changes and be unhappy. 

Perhaps you can engage Ryan to assist in effort. (I think this was already discussed in the past)

Comment 21

[Magnus Melin [:mkmelin]]

(In reply to Wayne Mery (:wsmwk) from comment #20)
> we do not have a high percentage of users abandoning
> betas because of add-ons (thankfully) 

Yes but beta users would know to look out for such things, and reasonably would be a lot more tech savy than the average user.

Comment 22

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin from comment #21)
> (In reply to Wayne Mery (:wsmwk) from comment #20)
> > we do not have a high percentage of users abandoning
> > betas because of add-ons (thankfully) 
> 
> Yes but beta users would know to look out for such things, and reasonably
> would be a lot more tech savy than the average user.

Miscommunication - non-beta users was not on scope of my comment.  My point was strictly about beta users relative to fallen's comment 16 ...

... which taken a step further (and mind you this is pure speculation), we could lose beta users if disable legacy addons and don't communicate what they should expect to see. And, to Fallen's comment 19, how we would like them to help us (if they can) to by giving feedback to us and to add-on authors.  

I agree we need to move in the direction of disabling bad addons, but it doesn't need to be a straight cutoff with no warning, no docs, and no coordination with support folks - even though it is "just beta".

Comment 23

[Jorg K (CEST = GMT+2)]

Text for the add-on authors:
https://docs.google.com/document/d/1VdjXJG8Gp6fKBlMQLJflOIGrPmqAZTy7PY3_bNfedZE/edit