How to handle addon failures in TB 45.0

Wayne Mery (Thunderbird QA) vseerror at
Mon May 2 20:20:08 UTC 2016

On 4/28/2016 3:52 PM, R Kent James wrote:
> Our managing of addon updates is fairly problematic now in Thunderbird,
> as we rely on authors to test and update addons, but assume that addons
> are compatible by default. This results in a number of addons that break
> TB when installed on update.
> Rather than just mark these as "not our problem" I suggest instead that
> we collect names and versions of addons that are known to break core
> Thunderbird functionality, and use a blocklist update to block these. I
> would not do that for addons whose functionality breaks, only when the
> addon breaks seemingly unrelated core functionality.

(written 4/28)

Yeah, we need improvement for a better user experience.

I've been mulling over this area for a week. Every major version update 
(we don't tend to see them for point releases) has add-on problems in 
primarily these areas:
Chrome / Themes

A sampling of problem add-ons is listed at with 
emphasis on those that break Thunderbird.

Depending on what time frame your talking about, it's not obvious or 
straight forward how we should act :

A. Often we don't know which add-ons are problems until user updates are 
well under way. By the time we have enough info to blocklist, in many 
cases most users have dealt with an issue on their own.

B. It can be difficult to determine which add-ons are causing permanent 
or significant failure. And in v45.0 we have some add examples where:
B1. Starting in safe mode and restarting helps*
B2. disabling an add-on and reenabling helps*
B3. to a lesser extent, (I think we've had reports of some add-ons 
(excluding lightning) not updating reliably (conversations?)

C. The bar for setting blocklists should be fairly high, lest every 
problem be grounds for blacklisting a failing add-on.  Examples done in 
past releases: foxyproxy  (which caused a topcrash), trackerbird (which 
caused a topcrash)

In short, we need a protocol with standards. With tools which include 
more than blocklisting.

I'd like a proactive step, which is maintain a list of addons that 
typically break, and have a set of testers bang on them in beta. Yes, it 
puts a burden on us that doesn't really belong on us but with the author 
of the add-on. But it's better IMO than dealing with the resulting 
support workload and the user pain during release.

* We're seeing many reports of this in SUMO. I don't recall seeing such 
a volume reports in version 45.0.

More information about the tb-planning mailing list