Closed Bug 1451097 Opened 2 years ago Closed 2 years ago

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

Categories

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

enhancement
Not set

Tracking

(thunderbird60 fixed, thunderbird61 fixed)

RESOLVED FIXED
Thunderbird 61.0
Tracking Status
thunderbird60 --- fixed
thunderbird61 --- fixed

People

(Reporter: mkmelin, Assigned: mkmelin)

References

Details

Attachments

(2 files)

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.
This should do it.
Attachment #8964671 - Flags: review?(jorgk)
Comment on attachment 8964671 [details] [diff] [review]
bug1451097_addon_incompatible_default.patch

Excellent!
Attachment #8964671 - Flags: review?(jorgk) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/722576b33822
make add-ons in-compatible by default for TB 60 and beyond. r=jorgk
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 61.0
Version: 52 Branch → Trunk
That killed Mozmill testing on beta :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
We probably just want to put some very large version number in there so we never have to touch it.
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.
(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 ;-)
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/60307cfe14dd
Follow-up: Lift maxVersion for Mozmill, JS Bridge and test add-ons to *. rs=bustage-fix
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
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)
Attachment #8964725 - Flags: review?(mkmelin+mozilla) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/de5ce5f50db7
Follow-up: No strict add-on checking on Daily. r=mkmelin
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.
(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
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?
Flags: needinfo?(philipp)
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.
Flags: needinfo?(philipp)
> 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)
(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.
(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".
Summary: make add-ons in-compatible by default for tb60 and beyond → make add-ons incompatible/not compatible by default for tb60 and beyond
See Also: → 1452505
See Also: → 1456988
Component: General → Add-Ons: General
You need to log in before you can comment on or make changes to this bug.