<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<br>
<div id="smartTemplate4-quoteHeader">
<style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style><br>
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>Re:
How to handle addon failures in TB 45.0<br>
<b>From:</b>Matt Harris<br>
<b>To:</b>Tb-planning <br>
<b>Sent: </b>Friday, 29/04/2016 02:47:26 02:47 GMT ST +0100
[Week 17]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite"
id="mid_721fa8d2_4f39_9dbc_66d5_c088d93774d9_gmail_com"
cite="mid:721fa8d2-4f39-9dbc-66d5-c088d93774d9@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">On 29/04/2016 5:22 AM, R Kent James
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_68108a89_6bf1_f1a7_3e94_e5a41939d308_caspia_com"
cite="mid:68108a89-6bf1-f1a7-3e94-e5a41939d308@caspia.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<i>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></blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<p>e.g.: <a class="moz-txt-link-freetext" href="http://quickfilters.mozdev.org/bugs.html">http://quickfilters.mozdev.org/bugs.html</a><br>
</p>
<p>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). <br>
</p>
<p>Problems (apart from discoverability): <br>
</p>
<p>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.</p>
<p>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.<br>
</p>
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
<a class="moz-txt-link-freetext" href="about:config">about:config</a> 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.<br>
<br>
<blockquote class=" cite"
id="mid_721fa8d2_4f39_9dbc_66d5_c088d93774d9_gmail_com"
cite="mid:721fa8d2-4f39-9dbc-66d5-c088d93774d9@gmail.com"
type="cite"><i>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.<br>
<br>
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. <br>
<br>
I am all for the idea, but I don't know how to make it work<br>
<br>
Matt<br>
</i> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>