Add-ons guide 63
On 11-02-2019 13:51, Jonathan Kamens wrote:
On 2/11/19 1:44 AM, Magnus Melin wrote:
On 11-02-2019 03:14, Jonathan Kamens via Maildev wrote:
Regarding "Starting in Thunderbird 63, all XBL-bindings will be
removed from Thunderbird..." I ran the bugzilla query given there
and it looks like a lot of the XUL elements formally implemented
with XBL bindings are still not yet fully replaced (e.g., datepicker
https://bugzilla.mozilla.org/show_bug.cgi?id=1524456 appears to
still be a work in progress), which implies to me that it would be
folly for me to attempt to port any of my add-ons at this point
which depends on any of the XUL elements that are in the process of
being replaced, because it won't work. Is that correct?
In general it should work, but it depends on which binding you're
using, and how it is/was removed or converted. In the XBL removal
process some bindings are removed as unneeded, some converted to
using a standard HTML widget, some code just inlined, some are
converted into Custom Elements, and some are converted into objects
that get initialized through code. And some are in flux.
For the very common case that the binding is turned into a Custom
Element instead you do not need to adjust the markup.
Do the XBL bindings that no one has started to de-xbl yet still work,
or are they broken because the XBL infrastructure has been removed?
The XBL bindings we have still work. If something is broken (a few cases
atm) it's just because we haven't had the chance to fix them yet. The
XBL infrastructure is still there, though specific features that nobody
used may have been removed.
If the former rather than the latter, are people being careful to
maintain functionality when merging de-xbl changes into the trunk
Used and needed functionality: yes. Everything that's not used in
Thunderbird is out. In that regard there is not a feature parity with
the old widgets. I don't expect this to be much of an issue though.
I want to be clear here: I am asking these questions, and the other
questions I have asked in this thread, not just because I want the
questions to be answered on this thread, but also because they should
be answered in the document that add-on maintainers are being pointed
to as the definitive guide to porting their add-ons to current
Thunderbird.
I maintain the eleventh most popular add-on as well as nine others. If
people here are serious about thinking it's important for add-ons to
get updated to the current Thunderbird, as per the recent discussion
about what to do about abandoned add-ons, then you need to do as much
as you can to make the porting process as painless as possible. The
/minimum/ for that is comprehensive documentation that clearly answers
all the questions add-on maintainers are going to have. If I've asked
something here, then that means right now the documentation is
inadequate.I
I'm afraid there is no real upgrade guide for each and every scenario.
In short, do not expect XBL bindings to work. In particular, if you're
extending some XBL binding, you need to stop doing that. It's almost
guaranteed not to work by 68 as we hope to get everything converted over
by then. The good news is that extending a Custom Element is pretty
easy, you can check mailWidgets.js for some examples.
-Magnus
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
On 2/11/19 5:50 AM, Jörg Knobloch wrote:
So where is the problem?
The problem is that add-on maintainers shouldn't have to click through
to a freakin' Mercurial commit to get the answers they need to the
questions they have about how to port their add-ons.
The problem is that this page should answer all of the questions they have.
Which means that this page should have a sample manifest.json on it,
showing how all of the information currently represented in install.rdf
would be translated to manifest.json.
The problem is that the people maintaining this Wiki page seems to view
it sort of like a scratchpad, when what they should be trying to produce
is a user-friendly, comprehensive, accurate, accessible guide for what
add-on maintainers need to do to make their add-ons keep working.
See, for example, the page on developer.mozilla.org that was written
about how to convert a legacy add-on to bootstrapped when that first
became a thing. That page tries very hard to be user-friendly,
comprehensive, accurate, and accessible.
The Wiki page about TB 63+ does not.
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.
The problem is that the people maintaining Thunderbird (still) do not
seem to understand that the people who maintain add-ons are customers,
not collaborators, and the user experience for those customers is just
as important as the user experience for Thunderbird's end users, if they
want add-ons to keep working in TB 61+.
Jonathan Kamens
OK, this partially answers my question, though now I need to wait for
someone to confirm that ATN supports this (AND DOCUMENT HOW IT WORKS IT
ON THE WIKI PAGE).
But it still doesn't give a straight, yes or no answer to this question:
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.
It does not.
The fact that it uses the word "replace" implies that /maybe/ the old
file needs to be deleted, but it's ambiguous.
Why is it like pulling teeth to just get someone to clarify that simple
ambiguity -- here and on the wiki page?
So frustrating.
In any case, I guess now I also need to wait until the changes to
ChromeUtils.import() are documented on the wiki page before I make
another attempt at porting my add-ons.
jik
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/
The problem is that the people maintaining Thunderbird (still) do not
seem to understand that the people who maintain add-ons are customers,
not collaborators, and the user experience for those customers is just
as important as the user experience for Thunderbird's end users, if
they want add-ons to keep working in TB 61+.
The people maintaining Thunderbird do need input and collaboration from
add-on authors.
We do want to get away from the constant add-ons-need-to-update, which
is why we are moving to the WebExtensions based APIs. With that, there
is an API that we can semi stably maintain even when the internals
change. This is a pretty large change compared to the old-style add-ons
where there is no real API, but the add-on can do whatever it wants -
which is obviously hard to support.
-Magnus
On 11-02-2019 14:27, Jonathan Kamens wrote:
Why is it like pulling teeth to just get someone to clarify that
simple ambiguity -- here and on the wiki page?
For many questions, nobody has the answer handy. (I don't, these
developments have many turns, and then trying to keep track on what got
back-ported where is overwhelming.)
You seem to think people aren't willing to document, but the way this
works in core is we see one thing that breaks, then we fix it. There are
many many cases each week. There is no need to keep thinking of what it
used to be, so we just move on and forget. At least that's what I do.
-Magnus
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.
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
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.
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."
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.
Given these facts as I understand them, it does not make sense for me to
jump straight to a WebExtension.
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.
jik
On 2/11/19 7:35 AM, Magnus Melin wrote:
You seem to think people aren't willing to document, but the way this
works in core is we see one thing that breaks, then we fix it. There
are many many cases each week. There is no need to keep thinking of
what it used to be, so we just move on and forget. At least that's
what I do.
I think the documentation is inadequate and poorly structured.
Yes, part of that is because things keep changing and it's hard to keep
up. I sympathize with and understand that.
But part of that seems to be attitude, as you've illustrated yourself in
what you wrote above: "There is no need to keep thinking of what used to
be..."
But there is.
There is a need to think about what used to be to be able to document
the changes adequately for add-on maintainers who are trying to keep
their add-ons working during this transition.
And part of it also seems to be that, as I said before, the people
writing the documentation do not seem to have the time or inclination to
make it sufficiently clear and comprehensive.
For example, my question about whether install.rdf needs to be removed
was added (by someone else! I am not the only person with this question)
to the Talk page for the Wiki page on December 8, and two months later,
the page still hasn't been updated to clarify this.
jik