<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<div id="smartTemplate4-template">
<p>Hi,<br>
</p>
<p><img style="margin-top: 1em; float: right; box-shadow: 1px 1px
2px rgba(20, 20, 20, 0.4);" moz-do-not-send="false"
class="myLogo" src="cid:part1.4A81D2B1.BE621EC6@gmail.com"
alt="Get Thunderbird!" height="15" width="94">
</p>
</div>
<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>
<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:
Caution about Thunderbird 52 and binary extensions<br>
<b>From:</b>Chris <a class="moz-txt-link-rfc2396E" href="mailto:tb-planning@birdiesync.com"><tb-planning@birdiesync.com></a><br>
<b>To:</b>Tb-planning <br>
<b>Sent: </b>Wednesday, 16/11/2016 21:47:16 21:47 GMT ST
+0000 [Week 46]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite"
id="mid_af513284_116b_89ea_3096_b9f63e678368_birdiesync_com"
cite="mid:af513284-116b-89ea-3096-b9f63e678368@birdiesync.com"
type="cite">Hello,
<br>
<br>
BirdieSync software has a third-party add-on in Thunderbird which
relies on XPCOM and XUL through binary components, and uses the
needed XPCOM interfaces to access to contacts, calendars and mails
to provide synchronization with mobile devices.
<br>
</blockquote>
a lot of non-binary addons use (the scriptable parts of) XPCOM <i>directly
</i>as well.<br>
<blockquote class=" cite"
id="mid_af513284_116b_89ea_3096_b9f63e678368_birdiesync_com"
cite="mid:af513284-116b-89ea-3096-b9f63e678368@birdiesync.com"
type="cite">
<br>
The future disappearance of support of binary add-ons hugely
impacts BirdieSync since it requires a full rewriting of
Thunderbird add-on. Such a rewriting takes a lot of time,
introduces risk in term of regressions and takes time to deeply
test it.
<br>
<br>
Being able to still rely on binary add-ons in Thunderbird version
52 would leave more time to smoothly manage the transition.
<br>
</blockquote>
this might be not practicable if Mozilla scraps this for the M-C
codebase...<br>
<blockquote class=" cite"
id="mid_af513284_116b_89ea_3096_b9f63e678368_birdiesync_com"
cite="mid:af513284-116b-89ea-3096-b9f63e678368@birdiesync.com"
type="cite">
<br>
Now the question is to know what the impacts would be of such a
support. You mentioned that a problem could be the "stability of
interfaces and exported symbols over the lifetime of the product
in security updates". So I guess that if one XPCOM interface is
modified during a security update, it means that a binary add-on
relying on this interface could crash. The solution in this case,
could be to publish a new version of the add-on to adapt to the
binary changes (as it was done for all major versions of
Thunderbird). I also assume that the change of interface would
also impact Javascript add-ons, but with no risk of crash though.</blockquote>
Well changing in XPCOM interface can also lead to malfunctions in
scripted Addons, a full crash of the host (Tb / SeaMonkey) would be
a worst case scenario.<br>
<blockquote class=" cite"
id="mid_af513284_116b_89ea_3096_b9f63e678368_birdiesync_com"
cite="mid:af513284-116b-89ea-3096-b9f63e678368@birdiesync.com"
type="cite">Also can you confirm that in Thunderbird 52, all XPCOM
interfaces that were accessible through binary components will
still be accessible through JavaScript components ? (so not with a
complete change of interface like WebExtensions)
<br>
</blockquote>
XPCOM interfaces have always been changing, (albeit slowly) and we
as Addon authors should keep an eye on them. The Addon validation
process actually flags changed ones, but I am not sure whether it
flags the complete list. A complete "interface history" tool that
checks an Addon's code for recently changed XPCOM functions would be
a big help here.<br>
<blockquote class=" cite"
id="mid_af513284_116b_89ea_3096_b9f63e678368_birdiesync_com"
cite="mid:af513284-116b-89ea-3096-b9f63e678368@birdiesync.com"
type="cite">What are the forecasted availability of all XPCOM
interfaces in future releases of Thunderbird, even in Javascript,
since it seems that Firefox wants to restrict its available
interface to add-on developers to WebExtensions?
<br>
</blockquote>
As far as I know there is no immediate plan to scrap XPCOM support
for Thunderbird. I am hoping that we can fork the code in order to
avoid this as Thunderbird Addons are lot more "desktop-centric" than
browser addons.<br>
<br>
Axel<br>
<br>
</body>
</html>