Jörg Knobloch wrote on 03.12.18 16:52:

Thanks. I added some intro text.

Ben

Started looking at porting my bootstrapped add-ons to TB 63+.

Questions I've encountered so far:

1. 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.

2. Does chrome.manifest still work?

  jik

On 12/3/18 10:52 AM, Jörg Knobloch wrote:

Also, how do I specify app version compatibility in manifest.json? I
don't see that documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json.
Is there somewhere else I should be looking?

On 12/3/18 10:52 AM, Jörg Knobloch wrote:

Other things on this page I am currently finding confusion:

The description of the removal of stringbundleset/stringbundle is
confusing. FIrst it says to use Services.strings.createBundle(...)
instead of using stringbundleset/stringbundle in XUL, but then below
that it says "In order to use stringbundles, you need to load
stringbundle.js". It's not clear whether that's an either/or. I.e., if I
include stringbundle.js in my XUL, then can I still use
stringbundleset/stringbundle?

It would be helpful if the documentation of things that have been
removed would also document when their replacements were added. For
example, when it says that insertItemAt and removeItemAt are gone and
insertBefore and remove should be used instead, it should say what
Thunderbird version first supported insertBefore and remove, so I know
whether I need to have backward-compatibility code in my add-on to
support older Thunderbird versions.

There's a sentence in the "Removed in Thunderbird 61" section: "You can
also use .setUnsafeInnerHTML() or document.allowUnsafeHTML = true, as a
workaround to the above, see here.", but the antecedent to "above" is
unclear so this sentence doesn't seem to make any sense.

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?

Thanks,

  jik

On 12/3/18 10:52 AM, Jörg Knobloch wrote:

On 11-02-2019 03:14, Jonathan Kamens via Maildev wrote:

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.

 -Magnus

On 11/02/2019 02:02, Jonathan Kamens wrote:

If you convert to a restartless add-on, you don't need manifest.json. If
you want to leave your add-on "as is" and use TB's overlay loader, then
you have to convert install.rdf to manifest.json.

An example is given:

===

See Lightning as an example:
https://hg.mozilla.org/comm-central/rev/e81f4b59a00a7d3e18d50fd3851ecbd47762a186#l2.5

===

There was also some discussion on specifying the compatibility, see:

http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2019-January/001351.html

Quoted here as plain text below.

Jörg.

===

On 24/01/2019 12:40, Graeme wrote:

somewhere....

Well, this is what the documentation says:

https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63#.22Legacy.22_XUL_extensions_with_overlays

To use this overlay loader, XUL overlay legacy extensions must replace
install.rdf file with a WebExtensions style manifest.json file, which
includes the key "legacy" set to true. See Lightning as an example:
https://hg.mozilla.org/comm-central/rev/e81f4b59a00a7d3e18d50fd3851ecbd47762a186#l2.5
(Note: In this changeset the @variables@ are build variables, add-ons
need to use fixed strings).

The changeset has this:

{
+  "manifest_version": 2,
+  "name": "Lightning",
+  "description": "Integrated Calendaring & Scheduling for your Email
client",
+  "version": "@LIGHTNING_VERSION@",
+  "author": "Mozilla Calendar Project",
+  "homepage_url": "https://www.mozilla.org/projects/calendar/",
+  "legacy": true,
+  "applications": {
+    "gecko": {
+      "id": "@XPI_EM_ID@",
+      "strict_min_version": "@THUNDERBIRD_VERSION@"
+    }
+  },
+  "icons": {
+    "32": "chrome/skin/linux/calendar/cal-icon32.png"
+  }
+}

So where is the problem? I have this in one of my manifests:

{
  "manifest_version": 2,
  "name": "ThunderHTMLedit",
  "description": "xxx",
  "version": "2.0.0",
  "author": "Jorg K",
  "legacy": true,
  "applications": {
    "gecko": {
      "id": "jorgk@thunderHTMLedit",
      "strict_min_version": "64"
    }
  },
  "icons": {
    "32": "chrome://thunderHTMLedit/skin/html-icon.png"
  }
}

Does that not work?

Jörg.

On 2/11/19 1:44 AM, Magnus Melin wrote:

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?

If the former rather than the latter, are people being careful to
maintain functionality when merging de-xbl changes into the trunk, or is
it possible that add-on maintainers will run into bindings that have
been only partially converted and are therefore broken in a nightly build?

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.

  Jonathan Kamens

On 2/11/19 5:42 AM, Jörg Knobloch wrote:

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. A moving target is hard enough to
hit. A moving target that I can't even see is pretty much impossible.

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?

Regarding the "Does chrome.manifest still work?" question, I'm sorry, I
should have been more specific. Given that apparently manifest.json has
its own mechanism for localization, I was specifically concerned about
whether localization in chrome.manifest (e.g., lines like "locale 
sendlater3      bg      chrome/locale/bg-BG/") will work as expected in
XUL files. It looks to me like it probably will, but I am looking for
reassurance on this question, and I think other add-on maintainers
reading this page will as well.

  jik