Thunderbird and Addons
pidgeot18 at gmail.com
Wed Aug 26 20:14:41 UTC 2015
On 08/26/2015 02:44 PM, R Kent James wrote:
> It would be good to inform us of any binary extensions that are out
> there and your needs.
This is extremely crucial advice to add-on developers. Anything that
cannot be satisfied with js-ctypes we should be well-informed of,
because we're unlikely to be able to maintain this.
> We have no current plan for dealing with the XUL deprecation issue. We
> don't get invited to sit at the cool kids table anymore, so this is
> hitting us about the same time it is hitting you (though I suspect the
> discussion was public if we had looked hard enough).
In a recent message, I've referred to the XUL/XPCOM issue as a "looming
disaster" (to steal the term from a video game). XUL we're going to have
to move away from, for sure. I do suspect, however, that there will
remain a chrome/content divergence in the layout engine without HTML,
and if that is the case, we should be able to use WebIDL to bridge JS
and C++ in a post-XPCOM world (I already know at a high-level what needs
to be done, and I've had support from bz about our use cases here in the
past). I do have ideas on how to do that. It's very unclear to me how
WebExtensions would handle custom WebIDL APIs, but if that is possible,
we could use it.
The bigger problem with the deletion of XUL is that XUL has some
high-quality widgets that are very difficult to code in pure
HTML--namely, I'm referring to the <tree> widget. Honestly, this is
something that I feel Mozilla should be providing if they move away from
XUL, but I doubt they will (judging from the response to the last XUL
tree question on m.d.platform).
> At least for Thunderbird, we have no current intention of either
> trying to reduce the power of addons, nor trying to be compatible with
> some industry-wide standard for addons (since there is no equivalent
> to "Web Extensions" for email clients). We're a different product than
> Firefox with different needs. But the prospect of trying to do our own
> thing here independent of Firefox would be enormously challenging.
There are some extensions for FF that do things like add new protocol
handlers whose support would require some sort of hooks that we could
likely abuse/twist for our ends. Some of the documentation makes it
clear that the add-ons team has no answers for these questions (nor even
really considered them too hard). This makes proactive damage control
extremely difficult on our end (or even for many/most add-on authors).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning