How to handle addon failures in TB 45.0
axel.grude at gmail.com
Fri Apr 29 10:25:53 UTC 2016
> *Subject:*Re: How to handle addon failures in TB 45.0
> *From:*Matt Harris
> *Sent: *Friday, 29/04/2016 02:47:26 02:47 GMT ST +0100 [Week 17]
> On 29/04/2016 5:22 AM, 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.
> /All good Kent, but who is the arbiter. I am regularly advised by users that
> following a safe mode start they have narrowed it down to say lightning. Do we take
> their word for it. A read of the reviews on AMO makes it obvious we can not rely on
> users to be able to identify anything. So do we set up a testing process? File a
> Bug? /
I would like to share my own process when one of my own Addons is identified for a
breakage. I immediately ask the user to file a bug in my own (mozdev.org based)
database, unless I have good reason to believe it was caused by a different Addon.
And usually send him (her) a self-patched version of console2 (because the one
currently on AMO is broken in Thunderbird 45; I keep bugging the owners to include my
patches), and a screenshot that shows how to set it up for showing All chrome messages
(err,wrn,msg,js,chrome) and also warn them to switch off content logging as it usually
is a distraction in Thunderbird.
I then advise to clear the error console immediate before the test and describe the
text, outcome and copy the console log (as text!!!). If I can I try to reproduce the
bug and upload a fixed version with a unique prerelease number. I also immediately log
the bug in my (future) version history on my support page.
Now this is a process I have developed over the years with all my addons and it takes
some discipline and routine to follow through, but if it could somehow be supported by
the AMO pages (at least displaying open bugs prominently on the first page) that would
indeed be a great service to the users. I don't think users can be expected to search
for bugs in various databases themselves. On my support pages I have a "bugs" page
that lists the last 10 items, before people start to raise bugs, so that may be
helpful in a way if they even click the support link:
Bugs are [hopefully] closed when I release a new version of my addon containing the
bugfix. (I do not close them just because I have uploaded a patch on Bugzilla).
Problems (apart from discoverability):
1) Bugzilla needs a valid email address to submit a bug, and it shows it in clear
text, many users are not comfortable with sharing their email on a public space. In
that case I usually raise the bug for them. If email addresses could be obfuscated on
the web page I believe adoption rate would be higher.
2) the mozdev.org bugzilla is proprietary and only discoverable via the mozdev pages.
And the server is slow and sometimes a little unreliable. It would be great if it
could be imported / included in the main bugzilla of mozilla.org, maybe under an
3) The biggest problem with bugs as we all know is the ability reproduce them
successfully, and the explanation of setting up a console log session. I haven't ever
managed to log on to another Thunderbird remotely or use screen sharing for
troubleshooting. I have a library in my Addons to switch on debug logging (a checkbox
in Addons options) and additional verbose logging of functional areas (right-clicking
the checkbox opens a readonly-filtered about:config view where these flags can be
set). I believe log sessions could be better integrated in the Thunderbird experience.
Such as a Help > troubleshoot item which would create a fresh log with appropriate
settings while users reproduce their issue and then package the log into an email /
attachment. Adding a "Make screenshot" button (like on the google trouble-shooters)
would be a bonus. Something like this would be awesome.
> /and wait for someone to verify it? In a week or two most issues disappear as the
> add-on author gets their new version through AMO review and the auto update takes over.
> It is not pretty and it does not account for the abandonware that litters AMO. It
> is not all that long ago that I saw folks explaining in Support how to install
> MailTweak and counseling that some features did not work, but remove local folders
> did still function. That has not been updated since Version 3 and is a disaster in
> the making.
> I am all for the idea, but I don't know how to make it work
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning