How to handle addon failures in TB 45.0
Wayne Mery (Thunderbird QA)
vseerror at lehigh.edu
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.
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
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