Posts by generalsync

Quote from Thunder

Da nach Thunderbird 78 vermutlich die WebExtension-Experiments gar nicht mehr möglich sein werden, ist dann sowieso Ende für meine Extensions

Ich sehe noch nicht, dass das Thunderbird-Team wirklich einen derartig nutzerfeindlichen Schritt unternehmen wird, aber ich kann auch nicht sagen das mich die derzeitige Kommunikation diesbezüglich beruhigen würde. Ich habe inzwischen mit dem Portieren meiner Add-ons begonnen und daher langsam einen groben Überblick über die aktuelle Situation – ohne Experiments wird imho derzeit kaum ein Add-on auskommen und die Dokumentation ist definitiv noch ausbaufähig. Zumindest mit Experiments geht aber mehr als ich erwartet hätte, sogar die XPCOM-Registry bleibt zugänglich. Letzteres ist aber auch bitter nötig, da das versprochene neue Adressbuch (noch?) fehlt und der Kalender keine API hat...

Rein technisch beleibt in Add-ons für 77.0b3 also alles machbar, was in vorherigen Versionen machbar war, auch wenn vieles neu geschrieben oder zumindest stark angepasst werden muss. Ohne Experimente wären alle regelmäßig von mir genutztes Add-ons dagegen überhaupt nicht umsetzbar. Ich würde hoffen, dass neue APIs den Experiment-Teil mit jeder Thunderbird-Version sukzessive verkleinern – aber es wird noch viele Jahre (Jahrzehnte?) dauern, bis die Mehrheit der Add-ons ohne Experimente auskommt.

Quote from Thunder

Ich konnte keinerlei Bereitschaft auf BugZilla sehen, dass jemand zukünftig passende APIs vielleicht erstellen würde.

Wenn ich die bisherige Kommunikation richtig verstanden habe, sollen Add-on-Entwickler selbst konkrete APIs implementieren (als Experiment) und zunächst im eigenen Add-on nutzen. Die Experimente sollten dann in der Bugzilla als Vorschlag/Diskussionsgrundlage eingebracht werden. Ich kann verstehen, wenn das Thunderbird-Team einen solchen "Machbarkeitsbeweis" sehen will, bevor sie sich eingehend damit beschäftigen (schließlich gibt es haufenweise Bugs, die bis zur Veröffentlichung gefixt werden müssen) – andererseits aber auch, dass der dafür notwendige Aufwand das Budget vieler Add-on-Entwickler übersteigen dürfte.

Ich will dich aber nicht von deinem Kurs abbringen: die Zukunft war schonmal rosiger und die Situation ist von "perfekt" meilenweit entfernt. Ich kann deine Entscheidung sehr gut nachvollziehen – schließlich ist das Portieren ist sehr zeitintensiv und schon die reguläre Pflege von Add-ons ist eine undankbare Angelegenheit. In diesem Sinne danke für deinen Beitrag zum Thunderbird-Ökosystem!

Quote from Thunder

Build mit integriertem OpenPGP.

Sobald das in einem testfähigen Zustand ist, sollte das auch über Treeherder kommen (bug 1628424). Derzeit enthält comm-central laut Bugzilla noch nicht alle Abhängigkeiten um den neuen Code nutzen zu können, klingt also so als wäre auch das selbst bauen noch nicht sinnvoll. Bislang erhält man mit damit wohl nur ein Thunderbird mit einigen internen Änderungen für OpenPGP, aber ohne nutzbare OpenPGP-Funktionen.

Quote from MHaefner

" deleted.sqlite "

Diese Datei enthält keine gelöschten Termine, sondern nur ein paar Metadaten. Es ist also nicht direkt möglich, gelöschte Termine wiederherzustellen.

Quote from MHaefner

Kann man abgelaufene Termine automatisch so löschen, daß darin enthaltene Wiederholungen erhalten bleiben ?

Man kann prinzipiell beliebige Einzeltermine einer Serie löschen: einfach die gewünschten Instanzen / Einzteltermine im Kalender markieren und via Rechtsklick und "Termin löschen" löschen (oder die Entfernen-Taste drücken). Die Rückfrage bezüglich der Terminserie sollte dann mit "Nur diesen Termin löschen" beantwortet werden – sonst werden auch zukünftige Termine gelöscht.

Eine automatische Löschung von Terminen ist meines Wissens aber nicht vorgesehen – bei Bedarf müssen Termine also von Hand gelöscht werden. Ich wüsste aber auch nicht, warum man Termine automatisch löschen wollen würde. Je nachdem was du mit der Löschung bezweckst, gibt es aber eventuell einen anderen Lösungsweg?

Quote from muzel

Vielleicht gibt es ja wirklich praktikable Anleitungen?

Ich habe TB > 68 bislang nicht gebaut, aber das Bauen von Thunderbird 68 ist unter Linux ziemlich einfach – wenn man Mercurial, einen Kompiler und übrige Abhängigkeiten installiert hat. Der offizielle Weg wäre für die aktuellste Alpha ein Sechszeiler:

hg clone http://hg.mozilla.org/comm-central # herunterladen von comm-central, das Alpha-Repository u.a. von Thunderbird
cd comm-central # in das heruntergeladene Verzeichnis wechseln
python client.py checkout # herunterladen weiterer Abhängigkeiten
echo "ac_add_options --enable-application=mail" > .mozconfig  # Thunderbird auswählen
echo 'ac_add_options --enable-calendar' >> .mozconfig # Lightning hinzufügen
./mozilla/mach build # Thunderbird kompilieren

Wobei die Zeile für Lightning eventuell inzwischen nicht mehr nötig ist – habe wie gesagt mit den aktuellen Versionen nicht probiert. Ich habe auch nie den offiziellen Weg getestet da ich die Abhängigkeiten selbst verwalten will. Aber das Prinzip sollte stimmen

Wobei man eigentlich nur selbst bauen muss, wenn man besondere Bedürfnisse hat. Für Standardfälle gibt es automatische Builds im Treeherder. Download z.B. durch Anklicken von einem grünen "B" neben einer kompatiblen Platform (Windows / Linux / OSX), die Dateien gibt es dann unten unter "Job Details". Für einen Linux-Build wäre z.B. die passende Datei dort i.d.R. "target.tar.bz2", für Windows vermutlich "setup.exe" und von OSX vermutlich "target.dmg" (?). Ist nicht für Endbenutzer gedacht, daher bedient es sich nicht sonderlich intuitiv...

Ich kann das Problem reproduzieren und erinnere mich auch dunkel, damit schonmal zu tun gehabt zu haben. Ich kenne aber spontan auch keine schnelle Lösung.

Es handelt sich vermutlich um eine Variante von Bug 1584222. Von den Entwicklern hat sich aber bislang niemand dazu geäußert. Ich würde vermuten, dass der Fehler irgendwo zwischen Datenbank und Anzeige sitzt (und sich also ohne Datenverlust beheben lässt), aber sicher bin ich natürlich nicht...

Quote from Zugus

Wundert mich aber, das nicht mehr Leute das Problem haben

Alle Programme machen doch genau das was sie sollen – es gibt durchaus Leute die ausfallende Serientermine als abgesagt markieren wollen (und vermutlich auch einige die Serientermine nicht nutzen und daher auch nicht betroffen sind). Auch wenn ich eine Option zum gelegentlichen "echten" Löschen eines Termine zugegebenermaßen auch schön fände, empfinde ich das nicht wirklich als Problem.

Oder meinst du die blassen Termine? Wie gesagt, die kenne ich ausschließlich von einer einzelnen, alten, fehlerhaften Kalender-App von Samsung. Alle anderen von mit getesteten Kalender-Apps haben – zumindest mit GeneralSync als Synchronisations-Backend – dieses Problem nicht.

Quote from Zugus

Aber habe es hier eine Lösung?

Nimm eine Kalender-App die Serientermine löschen kann oder frage bei deiner bestehenden Kalender-App an, ob man diese Funktion hinzufügen könnte. Auf Anhieb fällt mir da zwar keine ein, aber das Problem hat nichts mit Thunderbird (oder der Synchronisation) zu tun.

Quote from Zugus

Und dann bleiben noch die blassen Termine

Hatte ich überlesen... "blass" bedeutet vorläufig. Die Frage ist nur, warum die Termine als "vorläufig" markiert werden.

Ich kenne einen Bug in der Standard-App S-Planner auf alten Samsung-Geräten: dort wurden neue Termine immer als vorläufig eingestuft. Bei Änderungen passierte das aber – zumindest mit GeneralSync – meiner Erinnerung nach nicht. Da bei CalDAV-Änderungen nicht immer alle Daten übernommen werden können, kann es aber durchaus sein dass sich das mit anderen Synchronisationsmethoden anders verhält.

Eine andere Kalender-App kann eventuell helfen (z.B. Etar).

Kann es sein, dass es um einen Serientermin geht?

Viele Android-Kalender-Apps können einzelne Termine aus einer Serie nicht löschen, sondern markieren diese stattdessen als "abgesagt". Abgesagte Termine sind weiterhin im Kalender vorhanden (auch wenn sie von allen mir bekannten Android-Kalender-Apps nicht angezeigt werden) und werden in Thunderbird durchgestrichen dargestellt.

(Disclaimer: Ich nutze kein CalDAV – meine Erfahrung kommt von der direkten Synchronisation via GeneralSync, ohne die Daten über einen Server laufen zu lassen. Es könnte also auch ein CalDAV- oder Server-spezifisches Problem sein, dann kann ich nicht helfen.)

Quote from pezi

Wie kann man im TB Kalender die Termin Kategorien bearbeiten und neue dauerhaft speichern?

Die Liste der dauerhaft gespeicherten Kategorien befindet sich in den regulären Einstellungen¹ von Thunderbird unter "Kalender" (Kalender-Symbol in der Leiste links), als separater Tab "Kategorien". Die Kategorien bereits erfasster Termine werden dabei nicht verändert, die Liste dient nur der Anzeige in Thunderbird.

_____

¹ je nach Betriebssystem und Ansichtseinstellungen erreicht man die regulären Einstellungen via "Menü | Einstellungen | Einstellungen", "Menüleiste | Extras | Einstellungen" oder "Menüleiste | Bearbeiten | Einstellungen".

Quote from hambrecht.oliver

Hier konnte ich jedoch noch keine Option/Kombi finden, die mir das XPCOM zugänglich machen könnten.

Das wird es auch niemals geben, soviel wurde bereits beschlossen. Wenn du "alles" machen können willst (was XPCOM ja zulässt), brauchst du ein Experiment (das sollte dann auch irgendwie als "Berechtigung" dem Nutzer angezeigt werden, auch wenn es technisch keine Berechtigung ist).

Quote from hambrecht.oliver

Ist das tatsächlich ein Pferd, auf das man langfristig setzen kann?

Nein, soll es auch nicht sein. Rechne damit, dass das Experiment für jede ESR-Version vollständig neu geschrieben werden muss. Daher soll man es ja auch klein halten.

Quote from hambrecht.oliver

Gibt es einen sinnvollen Zugang zu diesen "Experimenten", so dass ich mir die Entwicklung, API etc. anschauen kann, um es als mögliche Option in betracht zu ziehen?

Ist zwar eigentlich für Firefox, aber ich würde zuerst die offizielle Übersicht unter https://webextensions-experiments.readthedocs.io/en/latest/ lesen und anschließend das dort verlinkte crashme anschauen. Dann sollte man loslegen können.

Beim Lesen der Übersicht nicht erschrecken: in Firefox-Beta und -Release sind Experiments bewusst gesperrt (d.h. Mozilla verbietet Drittentwicklern, Experiments zu veröffentlichen) – für Thunderbird ist eine solche Sperre meines Wissens bislang nicht geplant.

Edit: es gibt eine offizielle Dokumentation für Thunderbird. Frag mich nicht warum ich die gerade übersehen habe...

In 68 und allen bislang geplanten Versionen gibt es für privilegiertes JS eigentlich keinen Unterschied im Bezug auf Components.classes. Ich habe auch nichts gehört, dass sich das bald ändern soll.

Kann das sein, dass du unprivilegiertes JavaScript nutzt (d.h. eine "reine" WebExtension in einer Sandbox ohne XPCOM)? Dort ist nur erlaubt, was dir deine Berechtigungen explizit ermöglichen. Wenn du in einer WebExtension an XPCOM willst, musst du ein "Experiment" anhängen. Im Experiment darfst du privilegiertes JS schreiben – und für die WebExtension eine API bereitstellen, mit dem dieses dann privilegierte Funktionen nutzen kann.

Die Idee ist, dass Thunderbird solche Experimente einerseits mehr oder weniger direkt übernehmen kann, um so die WebExtension-Schnittstellen langfristig zu verbessern. Andererseits sollen größere Umbauten für neue Thunderbird-Versionen zukünftig nur in den Experimenten notwendig sein (diese aber dafür umso größer ausfallen!). Es empfiehlt sich also, die Experimente so klein wie möglich zu halten.

Quote from naralo

außerdem sollte irgendwie die Möglichkeit bestehen, dass die bearbeiteten Mails als "erledigt" gekennzeichnet werden können und auch der Mitarbeiter, die die mails zuweiset, den gesamten Kundenkontakt sehen kann.

Das klingt so, als suchst du eher nach einem "Ticketsystem". In einem solchen System ordnet ein Server die eingehenden E-Mails automatisch verschiedenen Vorgängen zu. Diese Vorgänge haben zusätzliche Metadaten und können als Ganzes delegiert oder als erledigt markiert werden; es ist in der Regel auch möglich, dass mehrere Mitarbeiter am selben Fall arbeiten und sich über den Vorgang austauschen können. So etwas kann ein "normaler" Mail-Server nicht leisten.

Einige dieser Systeme lassen sich auch via E-Mail (und damit Thunderbird) bedienen, wobei ich damit keine praktische Erfahrung habe. In jedem Fall braucht es dafür Serverseitig andere Software.

Für den Fall dass ich falsch geraten habe / der Vollständigkeit halber:

Quote from naralo

Also das haben wir zwar teilweise schon gemahct, ist aber natürlich nicht gerade effizient...

Über dieses "natürlich" lässt sich streiten. Der Gesamtaufwand sind ja zwei Klicks oder Tastenkombinationen (Weiterleiten + Senden), das Eintippen der ersten Zeichen des Ziel-Mitarbeiters (Empfängeradresse aus Adressbuch) und das Eintippen etwaiger Kommentare. Ich wüsste nicht, wie man im allgemeinen Fall irgendeinen dieser Schritte weglassen könnte.

Im konkreten Fall könnte man die Weiterleitung mit Filtern o.ä. eventuell auch noch beschleunigen – das hängt dann aber eben von den tatsächlichen Arbeitsabläufen ab.

Wenn du aber aus irgendwelchen gründen lieber gemeinsame Verzeichnisse nehmen willst, folge dem Vorschlag von NumLock. Freitext-Notizen gehen damit meines Wissens nicht ohne weiteres (eventuell mit einem Add-on, mir war da dunkel danach), Schlagwörter (Tags) je nach Mailserver schon. Wenn dein Server-Betreiber nicht direkt gemeinsame Verzeichnisse einrichten kann oder will, kann man dafür auch einfach ein weiteres IMAP-Konto missbrauchen. Generell hat ein gemeinsames Verzeichnis den Vor- und Nachteil, dass alle befugten Mitarbeiter immer auf alle dort gespeicherten Mails zugreifen können.

Quote from naralo

Was bietet sich da bei Thunderbird an?

Der natürliche Weg wäre eine Weiterleitung an die E-Mail-Adresse des Mitarbeiters, an den delegiert werden soll. Die neue Mail kann dann alle Hinweise enthalten, die an den Mitarbeiter gehen sollen, zur Referenz bzw. weiteren Bearbeitung steht unten oder im Anhang die originale Mail (je nach Weiterleitungs-Modus).

Wenn das aus irgendeinem Grund nicht reicht, wären vermutlich weitere Details hilfreich?

Quote from Hobomail

Zum manuellen Eingeben eine Frage: Ich habe auf einem email-Server (uni) bestimmt auch über 2 GB mails, daher würde ich alles erst mal offline kopieren und einrichten, damit diese emails nicht nochmal runtergeladen werden. Ist das ein Problem es offline zu machen?

Gute Frage, kann ich nicht sicher sagen. Für Mails gibt es hier im Forum einige andere Experten, die sich eventuell noch melden werden. Ich vermute, dass das erneute Herunterladen verhindert werden kann, wenn man alle Mails und den POP3-Status (popstate.dat) kopiert (während Thunderbird geschlossen ist). Wenn du eine aktuelle Sicherung hast, wüsste ich nicht was gegen probieren spricht

"Nicht funktioniert hat" ist nicht sehr präzise. Ich deute das mal als "es ist nichts passiert" (sonst ignoriere diesen Beitrag und schildere das Problem detailierter).

Klingt so, als wäre dein Profil beschädigt. Vielleicht ist beim Kopieren von Windows etwas schief gelaufen. Einen Batzen an Fehlern ist zwar normal (schließlich hast du z.B. eine zu aktuelle Version von Lightning installiert), aber Thunderbird sollte dennoch starten. Theoretisch kannst du noch einen Start im abgesicherten Modus probieren, in diesem Fall ist es aber vermutlich nicht mehr sinnvoll, lange nach Fehlern oder Ursachen zu forschen. Es geht viel schneller, Thunderbird einfach neu einzurichten und anschließend nur deine Mails und ggf. andere Daten aus dem alten Profil zu kopieren.

Ich würde also ~/.thunderbird komplett löschen, Thunderbird erneut starten und einrichten. Beim Import alter Daten kann das Add-on ImportExportTools NG helfen (ich habe damit keine Erfahrung, wird aber hier gerne empfohlen), ansonsten geht das mit mehr Arbeit auch manuell. Hier im Forum finden sich dazu auch einige Beiträge.

Quote from Hobomail

xxxxxetc.default-release

Das ist das Standard-Profil, auch wenn es in der profiles.ini anders steht. Die Details stehen in einem wenig menschenlesbaren Format in der installs.ini. In deiner Situation sollte es also reichen, das default-release Profil zu überschreiben.

Vorab: ich habe S/MIME nie aktiv genutzt. Daher kann ich zu a) auch nicht viel sagen – außer dass bei mir alle Zertifikate einiger meiner Gesprächspartner in den Thunderbird-Einstellungen unter "Erweitert | Zertifikate | Zertifikate verwalten" in der Kategorie "Personen" gesammelt wurden, obwohl ich S/MIME selbst nicht nutze. Es gibt also definitiv einen Automatismus

b) bei S/MIME ist ein Zertifikat "gültig", wenn eine autorisierte Zertifizierungsstelle dieses Zertifikat signiert hat. Üblicherweise kannst und sollst du die Vertrauenswürdigkeit der Zertifikate also nicht selbst prüfen. Das bedeutet natürlich, dass du allen autorisierten Zertifizierungsstellen uneingeschränkt vertrauen musst. Welche Zertifizierungsstellen autorisiert sind, kannst du aber in den Einstellungen einsehen und ggf. ändern. Wenn ein Zertifikat von einer anderen Stelle kommt, wird es normalerweise abgewiesen – du kannst individuelle Ausnahmen festlegen, um einzelne Zertifikate dennoch anzunehmen. Das ist vermutlich das "Vertrauen aussprechen", dass du meinst: in diesem Fall solltest du das Zertifikat mit deinem Gesprächspartner vorher auf einem sicheren, unabhängigen Kommunikationsweg abgleichen.

c) Es ist konzeptionell niemals möglich, Mails in einem IMAP-Posteingang oder seinen Unterordnern ausschließlich lokal zu speichern. Per Definition befinden sich darin alle Mails immer (auch) auf dem Server. Es wäre aber denkbar, mit einem Filter o.ä. Mails nach "Lokale Ordner" / "Local Folders" zu verschieben und erst dort zu entschlüsseln. Außer Enigmail kenne ich aber kein Tool, das so etwas können soll.

Quote from Thunder

theoretisch geplanten "reinen" WebExtension-Welt

Ich habe noch keinen Beitrag seitens der Thunderbird-Entwickler gelesen, in dem ernsthaft über eine baldige Beendigung der Experiments nachgedacht wurde – ich vermute das meinst du mit dem "theoretisch" . Mozilla hat das im Firefox zwar schon gemacht, die Ergebnisse dort waren aber desaströs, sodass man diesen Fehler hoffentlich nicht auch im aus Add-on-Sicht deutlich komplexeren Thunderbird wiederholen wird.

Nach Möglichkeit sollte ein guter Teil der Add-ons weitgehend ohne Experiments auskommen, aber ich glaube nicht, dass sie jemals vollständig abgeschafft werden. Selbst Firefox hat meines Wissens keine Pläne, Experiments jemals zu entfernen – nur ist diese Funktion in normalen Builds zumindest für Add-ons von Drittanbietern gesperrt. Da Thunderbird aber auch andere Funktionen zur Einschränkung der Nutzer nicht übernommen hat (z.B. zentrale Signierung von Add-ons), bin ich da (zumindest noch) guter Dinge.

Quote from Thunder

Der frühere Vorteil war meines Erachtens nur Existent, da sich über Jahre fast nichts zentrales an Thunderbird geändert hatte.

Ich merke, dass ich von zwei verschiedenen "früheren" Zeiten geredet habe, ohne diese vernünftig zu differenzieren. Sorry für die Verwirrung.

Ganz früher (vor Gecko 2) haben Add-ons ähnlich funktioniert wie WebExtensions mit einer "weichen" Form von Experiments: es gab ein paar (wenige) definierte APIs, die als "frozen" markiert wurden und für Add-ons stabil bereitstanden. Der Rest konnte sich zwischen Releases ändern (und hat das auch), die Add-on Entwickler mussten hier regelmäßig anpassen. Beide Typen von APIs standen gleichwertig im selben System, sodass man weitgehend reibungslos immer die API benutzt hat, die am besten passt. Änderungen an den nicht als "frozen" markierten APIs wurden nach Möglichkeit so durchgeführt, dass Add-ons nicht allzu sehr betroffen waren und sich der Aufwand für jede neue Version in Grenzen hielt. Dennoch war in der Regel ein Update von jedem Add-on für jede neue Version nötig (es gab aber noch keine Rapid Releases, in der Praxis war das also weniger schlimm als es klingt). Das ist das Niveau zu dem wir mit WebExtensions hoffentlich zurückkommen.

Dann hat Mozilla "frozen" abgeschafft – die Änderungen hielten sich aber weiterhin in Grenzen. Spätestens seit der Übergabe von Thunderbird an die Community ist die Entwicklung von Thunderbird weitgehend stehengeblieben – Add-ons wurden in dieser Zeit sogar ohne Freigabe durch den Entwickler automatisch als kompatibel eingestuft. In dieser Zeit hat sich wie von Thunder erwähnt einiges an Problemen angesammelt und viele Add-on-Entwickler haben ihre Add-ons alleine zurückgelassen (sie funktionierten ja noch). Das ist die Zeit in der gar keine Updates nötig waren.

Aus meiner Sicht sind WebExtensions die nächsten "frozen"-Interfaces, wenn auch deutlich mächtiger. Das bringt zunächst mal Ruhe rein, aber Add-on-Updates wird man weiterhin regelmäßig brauchen. Die Zeit von Add-on-Kompatibilität ohne Updates ist dagegen vorbei.

Quote from Thunder

Es gab faktisch einen Stillstand und somit einen "Entwicklungs-Stau", der sich momentan halt mit relativ schmerzhaften (weil auch ungewohnten) Umbrüchen rächt.

Die jetzt anstehenden schmerzhaften Änderungen kommen aber aus meiner Sicht eher von Firefox als von Thunderbird. Im Zuge der aktuellen Umbauten kann man aber hier und da auch ein bisschen Fortschritt in "Thunderbird-eigenen" Altlasten sehen.

Quote from Boersenfeger

Wenn der Umstieg erst Mal geschafft ist, wird es aber keine großen Änderungen mehr geben, so dass die Pflege wesentlich einfacher wird als bisher...

Auch wenn ich eher optimistisch eingestellt bin: nein, die Pflege von Add-ons wird nicht einfacher als in der Zeit "vor" den WebExtensions, damals waren praktisch keine Änderungen von Add-ons seitens ihrer Entwickler nötig. Daher sind ja so viele Add-ons weggefallen: viele hatten einfach seit Jahren keinen Entwickler mehr, der sich um sie kümmert. Es wird aber (hoffentlich) einfacher als in der Umstiegs-Phase, in der wir uns gerade befinden.

Deutlich einfacher wird dagegen die Pflege von Thunderbird selbst, da man sich nicht mehr so sehr um Add-ons kümmern muss – aus Rücksicht auf Add-ons waren viele Änderungen dort nicht möglich. Jetzt gibt es die politische Entscheidung, einen begrenzten Funktionsumfang via WebExtensions dauerhaft anzubieten und auf alle anderen Funktionen keinerlei Rücksicht mehr zu nehmen (das ist deutlich besser als in Firefox, dort wurden alle anderen Funktionen stattdessen für Add-ons gesperrt).

Wenn ein Add-on also mit den WebExtension-Dingen auskommt, wird es also langfristig mit genauso wenig Pflege auskommen wie ein altes Add-on in alten Versionen von Thunderbird. Ansonsten wird es für den Add-on-Entwickler aufwändiger als "früher", da alle darüber hinausgehenden Funktionen für jede neue Version von Thunderbird neu angepasst werden müssen.

Quote from edvoldi

So wie es aussieht, wurde auch die xul Unterstützung entfernt.

Nicht wirklich. Es sind wohl noch fast alle XUL-Elemente da (zumindest Stand Dezember 2019). Diese stehen nun halt in einem xhtml-Dokument statt in einem XUL-Dokument.