How to handle addon failures in TB 45.0

Axel Grude 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
> *To:*Tb-planning
> *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:

e.g.: http://quickfilters.mozdev.org/bugs.html

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 
"Addons" component.

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
>
> Matt
> /
>
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20160429/675dd71f/attachment.html>


More information about the tb-planning mailing list