Add-ons guide 63
Touché. Clearly, I am having a hard time keeping the terms legacy,
bootstrapped, non-bootstrapped, and restartless straight. Apparently I
am not the only one
https://wiki.mozilla.org/Talk:Thunderbird/Add-ons_Guide_63#Name_confusion.
Please do not let my error obscure the larger point that the
documentation is not adequate.
jik
On 2/11/19 8:06 AM, Jörg Knobloch wrote:
On 11/02/2019 13:05, Jonathan Kamens wrote:
I read the whole page, Jörg. Several times. I know what the page
says. I am talking about a legacy, non-bootstrapped add-on, not a
bootstrapped add-on. And regardless of how clear you may think this
language -- "XUL overlay legacy extensions must replace install.rdf
file with a WebExtensions style manifest.json file" -- it doesn't
answer my question, or I wouldn't have asked it. So, please go read
my question again, assuming that I actually read the documentation
and I'm asking things that I didn't think were addressed adequately
by the documentation, rather than assuming that I am an idiot. If
assuming that I am an idiot was not your intent, then check your tone.
Again: Do I need to delete install.rdf from my bootstrapped, legacy
extension for it to work with current Thunderbird, or can I leave
install.rdf and add manifest.json, and if I do need to delete
install.rdf, then how do I publish my extension on ATN in a way that
is compatible with both TB 60 and the newer version?
It's nice that people in the same community working on the same
Thunderbird ecosystem treat each other so kindly (not) :-(
I did read your initial request, and I did "go read [your] question
again":
On 11/02/2019 01:55, Jonathan Kamens via Maildev wrote:
Started looking at porting my bootstrapped add-ons to TB 63+.
And for bootstrapped add-ons the answer is pretty clear: install.rdf:
YES, manifest.json: NO. That's all I said.
If you read your quote above, in the first paragraph you're talking
about non-bootstrapped add-ons, in the second paragraph, like in your
original mail, you're talking about bootstrapped ones. So which is it?
Since we already established what needs to be done for bootstrapped
add-ons, let's now talk about non-bootstrapped XUL overlay add-ons.
They need to replace install.rdf with manifest.json. I have heard of
experiments where both files are present in the add-on, but I don't
know whether it works. You can either try it out or we can ask Geoff
or whichever add-on author it was who did the experiment.
Jörg.
On 11-02-2019 15:40, Jonathan Kamens wrote:
On 2/11/19 7:30 AM, Magnus Melin wrote:
On 11-02-2019 14:19, Jonathan Kamens via Maildev wrote:
Add-on maintainers are going to have to do a lot of work to port
their add-ons. The people who maintain Thunderbird need to do
everything they can to make that work as easy as possible.
If you want something stable, you should migrate to using the
WebExtension APIs, which sooner or later will be the only way to
create add-ons.
The documentation is here:
https://thunderbird-webextensions.readthedocs.io/en/latest/
Everything I have read so far has indicated that the coverage provided
by the WebExtension APIs available in Thunderbird is not yet adequate
for many extensions.
It depends on what the extension wants to do, really.
Just looking at the APIs documented on the page you referenced, I see
"first appeared in Thunderbird 66", "first appeared in Thunderbird
64", "first appeared in Thunderbird 63", "This is preliminary
documentation...". Still a moving target, it would seem. Therefore not
"stable."
While it's a slightly moving target, it doesn't mean that the APIs we
already implemented are likely to change significantly. There will be
adjustments as needed, and I don't expect we can have 100% stability
over time. Overall, changes would still be comparatively small.
If there were some guarantee from the Thunderbird developers that a
new version of Thunderbird won't be released to end users until the
WebExtensions APIs are sufficiently fleshed out to get most add-ons
most of the way there without having to write their own experiments,
then I would happily jump straight to WebExtensions and skip over all
the intermediate backward-compatibility stuff. But I have seen no such
guarantee; in fact, my understanding is that the whole reason why so
much effort is being put into all the intermediate stuff is because
there is no expectation that the WebExtensions APIs will be fleshed
out enough in the next GA release.
There was energy put into the backward-compatibility because otherwise
we were unable to develop replacing APIs before the old stuff was
un-supported. Technology wise it's a dead end that has a large
maintenance burden.
It's a bit unclear when we'll have all needed APIs in place, but thanks
to Geoff's great work in this area things are going to look pretty good
by Thunderbird 68.
If my understanding of these facts is incorrect, I would appreciate
being corrected.
I know that what you would like is for add-on maintainers like me to
dive in and attempt to rewrite our extensions as WebExtensions,
identify the gaps in API coverage, fill them with experiments, and
submit those experiments to be considered for adding to the
Thunderbird core application. That's reasonable, and if I had the time
to do it, I would. But I don't. My extension has nearly 8,000 lines of
code. I have a full-time job and a large family. Available blocks of
free time for working on my extensions are few and far between.
That's understandable. From the perspective of Thunderbird core, we do
want to enable creating extensions that do nice things. Yet, without
enough input from extension authors there will be gaps.
-Magnus
On 2/11/19 4:32 PM, Magnus Melin wrote:
I know that what you would like is for add-on maintainers like me to
dive in and attempt to rewrite our extensions as WebExtensions,
identify the gaps in API coverage, fill them with experiments, and
submit those experiments to be considered for adding to the
Thunderbird core application. That's reasonable, and if I had the
time to do it, I would. But I don't. My extension has nearly 8,000
lines of code. I have a full-time job and a large family. Available
blocks of free time for working on my extensions are few and far
between.
That's understandable. From the perspective of Thunderbird core, we do
want to enable creating extensions that do nice things. Yet, without
enough input from extension authors there will be gaps.
I think there are two parts to this. Yes, what you describe Jonathan
would be most ideal from our perspective, but we are aware that isn't
always possible.
If we can split this step up a bit then maybe it would be more tenable.
Try to see it this way, you are also spending the time to adapt to other
platform changes, so creating WX apis is really just another platform
change. You will eventually have to do this anyway, so better now in
smaller blocks than completely rewriting an 8k lines extension and
having to use what APIs are available.
As a first step, if you can identify APIs that would make sense for your
add-on (no code necessary), this would be good input already. This will
help distill functionality to APIs that are re-usable.
From that, you could propose the schema of the API, or maybe it would
even be part of the initial proposal. This shouldn't be a lot of work,
and is something that could be done in one of the smaller blocks you
have for working on your extension.
With an accepted API proposal, it could go into Bugzilla for someone to
build. If we see this is an API that a lot of add-ons would profit from,
it may be higher up on our list. If you have existing code that already
services this API, then it would just be a matter of taking that code
and wrapping the experiments API around it. Once you've done it, you'll
see it is fairly easy especially when wrapping existing code. We'll try
to pick up APIs that fit in well ourselves as well, so here is where we
can split the work.
What would arguably be more work than would fit into one of the small
time blocks is writing tests, but maybe we can find a solution for this
part as well, and that may involve some help from us.
I know exactly how it is to contribute under your circumstances (maybe
without the "large" part), I'm hoping though that by splitting this up
it would be easier to manage and be more rewarding as well.
Happy to chat on IRC if you'd like to go into details.
Philipp
Hi Philipp,
Yes, all this sounds perfectly reasonable. If/when I have more time to
work on my add-ons, I will start by inventorying the TB core
functionality that the add-on uses and identifying gaps between what it
uses and what is currently available in the WX APIs.
Having said that, I'd still rather someone else did it in exchange for a
(big) cut of the donations. ;-)
jik
On 2/11/19 11:26 AM, Philipp Kewisch wrote:
On 2/11/19 4:32 PM, Magnus Melin wrote:
I know that what you would like is for add-on maintainers like me to
dive in and attempt to rewrite our extensions as WebExtensions,
identify the gaps in API coverage, fill them with experiments, and
submit those experiments to be considered for adding to the
Thunderbird core application. That's reasonable, and if I had the
time to do it, I would. But I don't. My extension has nearly 8,000
lines of code. I have a full-time job and a large family. Available
blocks of free time for working on my extensions are few and far
between.
That's understandable. From the perspective of Thunderbird core, we
do want to enable creating extensions that do nice things. Yet,
without enough input from extension authors there will be gaps.
I think there are two parts to this. Yes, what you describe Jonathan
would be most ideal from our perspective, but we are aware that isn't
always possible.
If we can split this step up a bit then maybe it would be more
tenable. Try to see it this way, you are also spending the time to
adapt to other platform changes, so creating WX apis is really just
another platform change. You will eventually have to do this anyway,
so better now in smaller blocks than completely rewriting an 8k lines
extension and having to use what APIs are available.
As a first step, if you can identify APIs that would make sense for
your add-on (no code necessary), this would be good input already.
This will help distill functionality to APIs that are re-usable.
From that, you could propose the schema of the API, or maybe it would
even be part of the initial proposal. This shouldn't be a lot of work,
and is something that could be done in one of the smaller blocks you
have for working on your extension.
With an accepted API proposal, it could go into Bugzilla for someone
to build. If we see this is an API that a lot of add-ons would profit
from, it may be higher up on our list. If you have existing code that
already services this API, then it would just be a matter of taking
that code and wrapping the experiments API around it. Once you've done
it, you'll see it is fairly easy especially when wrapping existing
code. We'll try to pick up APIs that fit in well ourselves as well, so
here is where we can split the work.
What would arguably be more work than would fit into one of the small
time blocks is writing tests, but maybe we can find a solution for
this part as well, and that may involve some help from us.
I know exactly how it is to contribute under your circumstances (maybe
without the "large" part), I'm hoping though that by splitting this up
it would be easier to manage and be more rewarding as well.
Happy to chat on IRC if you'd like to go into details.
Philipp
I apologise for not replying earlier, as I have been extremely busy.
This is what I know:
It appears that yes, it is currently possible for an extension to have
both install.rdf and manifest.json manifests. I tested this on Daily,
which loads the JSON file, and on ESR, which loads the RDF file. The
uncertainty arose because for several versions (I think 63, 64, and
possibly 65), the presence of both manifests caused the extension not to
load. However, for my own extensions, I will not be making a version
with both manifests. There are too many differences to try to make one
extension version support both Thunderbird versions.
The addons website has been changed so that it presents the latest
compatible version of an extension. (Only if the user-agent string is
from Thunderbird. In all other cases it shows the latest version, like
it did before.) You can see this by searching for "Open With" in the
Add-Ons Manager. In ESR, v6.8.6 is offered; in beta or Daily, v6.9 is
offered.
Chrome manifests still work. To localise manifest.json (extension name
and description, etc.) you will have to use the WebExtensions L10n
format though. Needing both L10n formats does suck, I agree.
GL
On 11/02/19 13:55, Jonathan Kamens via Maildev wrote:
Started looking at porting my bootstrapped add-ons to TB 63+.
Questions I've encountered so far:
-
Do I need to /replace/ install.rdf, or can I leave it there for
compatibility with older Thunderbird versions and add manifest.json in
addition? It would suck if I have to maintain two different versions
of the add-on, one for TB 60 and below and one for TB 63 and above.
I'm not even sure ATN will effectively support that, and certainly it
will mean more work for reviewers, which I'd rather avoid. -
Does chrome.manifest still work?
jik
On Mon, Feb 11, 2019 at 1:16 PM Magnus Melin mkmelin+mozilla@iki.fi wrote:
On 11-02-2019 14:05, Jonathan Kamens via Maildev wrote:
Again: Do I need to delete install.rdf from my bootstrapped, legacy
extension for it to work with current Thunderbird, or can I leave
install.rdf and add manifest.json, and if I do need to delete
install.rdf, then how do I publish my extension on ATN in a way that
is compatible with both TB 60 and the newer version?
I think we fixed ATN to support this just recently. Someone could confirm.
Questionable if there is such a thing as compatible with both 60 and 68.
For one thing they changed how ChromeUtils.import() work just the other
week, in preparation for loading ES modules in a standard way. Maybe
it's possible to work around somehow, but it doesn't appear very
appealing, especially on top of all other changes. One add-on version
per Thunderbird version is the way to go.
-Magnus
Can someone please elaborate on ChromeUtils.import().
I thought this was the new way of importing stuff specific to FUEL or STEEL.
In my XUL-overlay add-on I still use Components.utils.import().
Is this basically the same thing? Is ChromeUtils the preferred way of
importing a module? Is Components.utils.import() deprecated? Does either
one have memory or performance issues? What are the advantages or drawbacks
of using either one?
When uploading an add-on that contains a manifest.json to ATN it gets
automatically approved because it's seen as a WebExtension, even if it's a
legacy XUL-overlay add-on. You only have to change the compatibility range
yourself and maybe add SeaMonkey, if your add-on is also compatible with
SeaMonkey. The add-on reviewers should check the auto approved queue to see
if there are legacy add-ons and verify that they don't do anything strange.
I've filed a bug for the auto approval of those hybrid extensions that
depend on the overlay loader, because they should be verified by add-on
reviewers before becoming available on ATN.
Onno
Sorry, I sent this message to the wrong address, so it got stuck somewhere.
Resending now, although it may be a bit outdated by now, but I still wanted
to share my 2ct…
On Mon, Feb 11, 2019 at 2:30 PM neandr neandr@gmx.de wrote:
Am 11.02.19 um 14:06 schrieb Jörg Knobloch:
They need to replace install.rdf with manifest.json. I have heard of
experiments where both files are present in the add-on, but I don't
know whether it works. You can either try it out or we can ask Geoff
or whichever add-on author it was who did the experiment.
Maybe Jörg had in mind Reminderfox.
That's a legacy, bootstrapped extension and is OK for TB60.X. So it has
a install.rdf
I tried to make it work also with TB61 etc and for that a manifest.json
was added. With TB60.x it was no problem to load and run and the current
release on ATN has both definition files.
My local dev versions of RmFX work somehow, but unfortunately there are
other problems to get a RmFX version with out glitches, a version which
could be delivered to the users.
So my learning was, it seems to be possible to have one release
running with both: TB60.x and higher TB6X.x versions. For sure that can
change in the future, we learned Mozilla/Thunderbird is a moving target.
If we like it or not, each addon author has to decide which TB version
he/she is going to support today .. and tomorrow.
We should acknowledge the TB team's efforts, they're doing a great job!
Whoever follows maildev a bit can only say: Thanks!
Günter
My add-on Mail Redirect also is an old XUL-overlay add-on and has both
a manifest.json with the "legacy" attribute and the original install.rdf
and chrome.manifest. The overlay loader that the Thunderbird developers
have built takes care of loading the extension in newer versions of
Thunderbird.
This way I had my add-on compatible with Thunderbird 6.0 up til 67.0 and
I hope it will remain that way with a little tweaking and changing until
the next release! After that I will probably have to convert it to a
WebExtension/MailExtension. (Is that name already officially changed?)
The Thunderbird developers are mostly that: Thunderbird developers. For
a large part they are also volunteers who have to deal with the constant
changes in Gecko and do their best to keep Thunderbird working. And if
time permits, improve it and add functionality to it.
Documentation as always isn't high on the list. I think that we as
extension developers sometimes are guinea pigs and we really do have to
collaborate with the Thunderbird developers to make thing work. At least
that's the way I do it. I do it by testing if my add-on works in
Thunderbird Daily or Beta, and if not, check where it is broken.
Sometimes it is broken because things have changed in Gecko and
Thunderbird needed to adapt and then my add-on also needs to adapt. If
this happens, I try to update the Add-ons Guide for Thunderbird 63,
which after all is a Wiki where every can contribute to.
Sometimes my add-ons stops working because something is borken in
Thunderbird itself, and then I file a bug, just like most of the other
beta testers out there.
Together we do our best to keep Thunderbird the mail client it is with
the add-on landscape it deserves.
Onno
On 14/02/19 20:29, Onno Ekker wrote:
Can someone please elaborate on ChromeUtils.import().
I thought this was the new way of importing stuff specific to FUEL or
STEEL.
In my XUL-overlay add-on I still use Components.utils.import().
Is this basically the same thing? Is ChromeUtils the preferred way of
importing a module? Is Components.utils.import() deprecated? Does
either one have memory or performance issues? What are the advantages
or drawbacks of using either one?
Yes this is the same thing. I'm not quite sure where I read it (might've
been bug 1425611 but I've never been there according to my history) but
ChromeUtils.import is a faster implementation of the same thing. Which
is handy because we use it a LOT.
When uploading an add-on that contains a manifest.json to ATN it gets
automatically approved because it's seen as a WebExtension, even if
it's a legacy XUL-overlay add-on. You only have to change the
compatibility range yourself and maybe add SeaMonkey, if your add-on
is also compatible with SeaMonkey. The add-on reviewers should check
the auto approved queue to see if there are legacy add-ons and verify
that they don't do anything strange. I've filed a bug for the auto
approval of those hybrid extensions that depend on the overlay loader,
because they should be verified by add-on reviewers before becoming
available on ATN.
Hmm, that's not intended, and bad, I'll have a look into that.
GL
Jonathan Kamens via Maildev wrote on 11.02.19 13:05:
The page is a little out of date, especially since M-C changed the ChromeUtils.import() mechanism at mozilla67 which will most likely break *all* add-ons :-(
This -- not keeping the documentation up-to-date as things change -- is why I waited until last night to even try to start porting my add-ons. I guess I should have waited longer.
Actually, you should have started earlier. If nobody tries to update their addon, then nobody will notice the problems in the documentation. The earlier you start, the better.
This is a community project. It's up to us now to do things, not wait for others to do it for us. "us" includes you.
This here is the wrong attitude:
I need to wait for someone to confirm that ATN supports this (AND DOCUMENT HOW IT WORKS IT ON THE WIKI PAGE).
Aside from the fact that shouting at others who are trying to help you is impolite, there is no point to "I need YOU to do it for me".
You try it out, you run into problems, you try to solve them yourself, and once you found the solution, you document it, and discuss it on an addons dev mailing list. The person to document it is *you* yourself.
DO I NEED TO DELETE INSTALL.RDF FROM MY LEGACY, NON-BOOTSTRAPPED ADD-ON FOR THE MANIFEST.JSON TO DO THE RIGHT THING, OR WILL THE SIMPLE PRESENCE OF INSTALL.RDF IN THE ADD-ON CAUSE IT NOT TO WORK? Y'all seem to think that the language in the wiki page makes this clear.
First: You started this thread with "porting my bootstrapped add-ons", while now you shout "NON-BOOTSTRAPPED ADD-ON". See where our confusion comes from? -- That's already been discussed, so let's not further elaborate this.
Second: It's quite simple to answer: Why don't you just try it out whether it works, in all the TB releases you want to support? Frankly, the core devs are currently not doing much more scientific work, either. It breaks, they fix it. It works, nobody looks. In all that fire fighting, documentation sometimes falls by the wayside.
Have you actually tried it? If so: What have you found? Please follow https://stackoverflow.com/help/how-to-ask as a minimum bar. The bar on this list is actually much higher than that, because unlike stack overflow, this is not a addon developer support forum. This is the mailing list for people who contribute code.
I think the documentation is inadequate and poorly structured.
Great. Fix it.
Ben
Hey all,
I don't think pointing fingers is the best approach here. I feel that Jonathan just feels his concerns are not heard, and is trying to flag some improvements that could lead to a better understanding for himself and others.
At the same time, we of course would appreciate community support in improving those docs and also the MailExtensions APIs.
Based on Jonathan's earlier response I feel he is well aware that contributing his time for creating APIs would benefit both his own add-on and possibly others.
Let's see what we can improve on our end, and I am sure we can work together to make MailExtensions a success!
Philipp
On 15. Feb 2019, at 12:15 AM, Ben Bucksch ben.bucksch@beonex.com wrote:
Jonathan Kamens via Maildev wrote on 11.02.19 13:05:
The page is a little out of date, especially since M-C changed the ChromeUtils.import() mechanism at mozilla67 which will most likely break all add-ons :-(
This -- not keeping the documentation up-to-date as things change -- is why I waited until last night to even try to start porting my add-ons. I guess I should have waited longer.
Actually, you should have started earlier. If nobody tries to update their addon, then nobody will notice the problems in the documentation. The earlier you start, the better.
This is a community project. It's up to us now to do things, not wait for others to do it for us. "us" includes you.
This here is the wrong attitude:
I need to wait for someone to confirm that ATN supports this (AND DOCUMENT HOW IT WORKS IT ON THE WIKI PAGE).
Aside from the fact that shouting at others who are trying to help you is impolite, there is no point to "I need YOU to do it for me".
You try it out, you run into problems, you try to solve them yourself, and once you found the solution, you document it, and discuss it on an addons dev mailing list. The person to document it is you yourself.
DO I NEED TO DELETE INSTALL.RDF FROM MY LEGACY, NON-BOOTSTRAPPED ADD-ON FOR THE MANIFEST.JSON TO DO THE RIGHT THING, OR WILL THE SIMPLE PRESENCE OF INSTALL.RDF IN THE ADD-ON CAUSE IT NOT TO WORK?
Y'all seem to think that the language in the wiki page makes this clear.
First: You started this thread with "porting my bootstrapped add-ons", while now you shout "NON-BOOTSTRAPPED ADD-ON". See where our confusion comes from? -- That's already been discussed, so let's not further elaborate this.
Second: It's quite simple to answer: Why don't you just try it out whether it works, in all the TB releases you want to support? Frankly, the core devs are currently not doing much more scientific work, either. It breaks, they fix it. It works, nobody looks. In all that fire fighting, documentation sometimes falls by the wayside.
Have you actually tried it? If so: What have you found? Please follow https://stackoverflow.com/help/how-to-ask as a minimum bar. The bar on this list is actually much higher than that, because unlike stack overflow, this is not a addon developer support forum. This is the mailing list for people who contribute code.
I think the documentation is inadequate and poorly structured.
Great. Fix it.
Ben
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net