Wobei Dein Tab-bezogener Ansatz auch Dillingers Button auf den Tab eingrenzen könnte/würde und der somit auch gar keinen globalen Rechte mehr hätte bzw. bräuchte.
Genau, das ist mein Ansatz. Niemand braucht Zugriff auf die globalen Einstellungen, sondern nur auf die lokalen, tab bezogenen Einstellungen.
Danke Thunder für die API. Für Thunderbird 102 schaffe ich es nicht mehr, mir das anzugucken, ich habe den "Need Info" offen gelassen, damit ich daran erinnert werden.
Wegen der Abhängigkeit von global Prefs, steht aber auch eine Änderung des Konzepts im Raum: Die globalen Prefs werden nur noch als Vorbelegung einer lokalen Einstellung benutzt (abgelegt im gMessageDisplay Objekt des Nachrichtenfensters). Die Anzeige ist dann nur von diesen lokalen Einstellungen abhängig. Das toggeln der Pref hat dann nur Auswirkungen auf neu geöffnete Nachrichten (weil die Vorbelegung geändert wurde), nicht aber auf bereits geöffnete Nachrichten. Das würde das Rücksetzen-Problem komplett eliminieren und du müsstest nicht mit globalen Prefs arbeiten.
Die Anpassung der Einstellung für ein bestimmtes tab ließe sich dann super in die messageDisplay API einbauen. Hab ich was übersehen?
Jedenfalls habe ich den "need-info" request im Kopf und komme darauf zurück.
Der "need-info" ist an mich 
Das mache ich, damit ich eine Überblick über die Dinge habe, die ich als nächstes machen will. Aber Feedback zu dem Thema ist auf jeden Fall hilfreich. Danke.
Das würde ich dann wieder als absolut kritisch ansehen, da ich damit ja auch jegliche Änderung der 3 Einstellungen mittels Thunderbirds eigener UI blockieren würde. Ich möchte dazu erst gar nicht an die Support-Szenarien denken. Das kommt gar nicht in Frage.
Ok, dass kann ich verstehen. Hatte daher die notification vorgeschlagen, die das dem User kommuniziert. Aber das ganz war nur eine Idee, wenn du sie nicht magst, ist das völlig in Ordnung.
Ich kann mir zur Unterscheidung von current per Thunderbird UI und current per Add-on-Dialog durchaus vorstellen, dass ich dies unterscheiden kann, da ich entsprechende eigene Listener ja beim Umschalten über meinen Dialog vorübergehend deaktivieren könnte. Aber das erscheint mir dennoch alles viel zu kompliziert. Ich muss da mal für heute einen Pause gedanklich einlegen und die nächsten Tage nochmal drauf zurück kommen. Vermutlich werde ich in der Zwischenzeit verschiedenes ausprobieren.
Ja, das scheint zu komplex. Ich wollte es ja gerade einfacher machen, nicht komplizierter.
Die größte Hilfe ist wahrscheinlich, wenn du es dokumentierst und dem User sagts, wo er die Einstellung im TB UI findet.
Zunächst: Das ist alles schon recht fortgeschritten. Dein Add-on hat große Schritte gemacht und die Pref Manipulation ist eine der wenigen Sachen, die mir beim review aufgefallen sind. Wenn es keine einfache Lösung gibt, dann reicht sicherlich auch ein Hinweis auf der Add-on Listing page.
Es gibt ja generell die Möglichkeit, Add-ons in die Liste der vorgestellten Add-ons aufzunehmen, was einen gravierenden Einfluss auf deine Nutzerzahlen haben könnte. Mein Augenmerk liegt hier ganz klar auf neuen Usern, die dein Add-on ausprobieren.
> 1. siehe oben: Dialog beim Deaktivieren/Deinstallieren des Add-ons
Zu deinem Vorschlag bzgl. Dialog beim Deinstallieren: Das geht mit hoher Wahrscheinlichkeit nicht, weil dein Add-on beim shutdown nicht wartet. Wenn der User im Dialog was klickt, ist dein Add-on code wahrscheinlich schon nicht mehr da. Ich selbst hab das noch nicht ausprobiert, habe aber von Dritten gehört, dass es problematisch ist und zu race conditions führen kann.
> 2. Das Add-on verändert nur auf Wunsch des Users Einstellungen. Der User könnte er im Text der Add-on-Dialogtexte darauf hingewiesen werden, dass es sich um Einstellungen handelt, die er in Thunderbird zurücksetzen könnte.
Das ist auf jeden Fall eine gute Idee, wenn dein Add-on nicht die volle Kontrolle über die Pref übernehmen will, sondern nur einen zweiten Weg eröffnen möchte, diese zu ändern. Wie oben geschrieben ist das der Hauptgrund für meine Anmerkung gewesen, da es nicht ersichtlich war, dass es eine Thunderbird-Einstellung ist, die da in deinen Add-On Einstellungen geändert wird.
> Ich verstehe gerade nicht, wann dieses Szenario eintreten soll.
Das Konzept meines Vorschlags war, das AHT die alleinige Kontrolle über die Pref übernimmt, damit du sauber auf einen Urzustand zurückgehen kannst, ohne grübeln zu müssen, was der Urzustand ist (weil die Pref u.U. außerhalb deines AHT option dialogs geändert wurde, egal wie)
original = vor Add-on-Installation
current = die Einstellung, die in deinem AHT options dialog vorgenommen wurde
Beim ersten Start gibt es kein "current" in deiner local storage, also nimmst du einfach den aktuellen Wert der Pref, den du auch in "original" speicherst. Ab diesem Zeitpunkt überwacht dein onChangePref listener die Pref und setz sie bei jeder Änderung (in about:config oder im TB options UI) auf deinen "current" Wert zurück. Du bist der einzige, der die Pref ändern kann. Du musst nix mehr unterscheiden.
Deine Ausführungen in #4 zeigen sehr schön warum die Manipulation von prefs kritisch ist. Idee:
* AHT sieht sich als Hauptverwalter für diese Pref. Das was bei dir eingestellt ist gilt.
* Beim ersten AHT Start/Install ist deine local storage leer, dann speicherst du den aktuellen Wert der Pref als "original" und als "current" in der local storage.
* registriere einen onPrefChange listener auf diese pref, der die pref bei jeder Änderung prüft und wenn er von "current" abweicht, setzt du ihn zurück (nach ein paar millisekunden) und gebe zusätzlich eine notification aus (https://developer.mozilla.org/en-US/docs/Moz…I/notifications) dass AHT die Pref gelockt hat.
* Du selbst kannst die Pref ändern, weil du vor der eigentlichen Änderung den "current" Wert in deiner local storage änderst, sodass der onPrefChange listener dann nix macht.
* Bei add-on shutdown revertest du auf "original" (vorher den onPrefChange listener entfernen)
* Bei add-on start, erzwingst du "current"
Jetzt kann es noch mit einem anderen Add-on, dass die gleiche Methode wählt, ein Gezanke um die Pref geben. Dafür könntest du einen rate limiter in deinen onPrefChange listener einbauen und den User wieder mit einer notification auf diesen Umstand hinweisen. Ich kenn aber derzeit kein add-on, dass das tut.
Das wäre solide, um die ganzen von dir aufgeführten Probleme zu umgehen. Ne andere Lösung fällt mir derzeit nicht ein.
Danke für die Erklärung. Mir ging es um die globale Einstellung "Externe Inhalte in Nachrichten", die dein Add-on schaltet.
Szenario: Aser hat keine Ahnung von den Thunderbird Einstellungen, installiert AHT und nutzt es um die globale Pref zu ändern. Für diesen User ist es nicht ersichtlich, dass er eine globale Pref ändert, sondern er "benutzt dein Add-on".
Er deinstalliert dein Add-on und hat keine Ahnung, wie er diese Einstellung ohne dein Add-On wieder ändern kann. Das gilt es zu vermeiden. Wenn es eine whitelisted prefs API geben wird, dann wird die auch alle Einstellungen zurücksetzen, die von Add-ons verändert wurden. Daher die Bitte: Speichere den Zustand aller prefs, die du dauerhaft änderst und reverte auf diesen Zustand, wenn den Add-on runterfährt.
Der Badge kann auch UTF8 Zeichen, was sehr schick aussieht:
Kommt darauf an, ob du schicke Darstellungen findest, die deine gewünschten Statusanzeigen repräsentieren können (welche sind das nochmal?)
Da es den browser-action-button nicht im message display window gibt, wollte ich davon abraten, den als Statusdisplay zu benutzen, wenn es den nicht überall gibt, da dein UI inkonsistent werden könnte.
Wenn der badge nicht passt, warum kannst du das icon des message display buttons nicht für den status benutzen?
Was die Sache etwas kompliziert macht: Alle action buttons aller tabs/windows sind gleich. Es gibt einen bug der individuelle Eigenschaft vorschlägt, hab da aber noch nicht reingeschaut. Das haben wir von Firefox geerbt.
Der action button ist in stand allone message windows nicht vorhanden, glaube ich. Warum benutzt du nicht direkt den message display button dafür? Du könntest eine badge für den status benutzen, wenn du das icon schon für was anderes verwendest.
DAV-4-TbSync wird es für Thunderbird 102 nicht mehr geben, weil Thunderbird jetzt sowohl das auto-discovery der Kalender macht als auch Kontakte beherrscht. Der minimale Vorteil den TbSync noch bietet (Kontake und Kalender zentral zu verwalten, etwas besserer CardDAV sync, Adressbuch UI), rechtfertigt den Aufwand nicht mehr. Wenn ihr nicht das exotische EAS Protokoll (EAS-4-TbSync) oder Google (Google-4-TbSync) benötigt, könnt Ihr TbSync löschen.
Nachtrag: Keine Ahnung, ob Thunderbird inzwischen auch die iCloud Kalender und Kontakte findet, das schien immer noch ein Problem zu sein.
Jetzt habe ich festgestellt, dass neue Kalendereinträge meiner Frau in TB nicht dargestellt werden. Bei meinem Kalender funktioniert alles. Kann mir jemand einen Tipp geben, wie ich die neuen Kalender-Einträge meiner Frau auch in TB sehe?
Der Kalender deiner Frau ist da, aber ist leer?
Der Kalender muß manuel aus- und wieder eingeblendet werden um neue Termine sichtbar zu machen. Lässt sich dies noch einstellen ?
Das wurde jetzt zum zweiten Mal reported. Sehr komisch, besonders weil TB91 ja schon so lange draußen ist. Kannst du mal deinen ganzen Account in TbSync löschen und neu anlegen? (Und gucken das nach dem Löschen auch alle Kalender weg sind).
Hilf das?
Du kannst aus
let hasHtmlMimePart = await new Promise(resolve => {
resolve ( browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug) )
});einfach
let hasHtmlMimePart = await browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug);machen.
Im obigen Beitrag habe ich die callbacks durch promisses ersetzt. Funktioniert das?
Ah, ok. Wenn die Sprache ein Grund dagegen ist, dann bleiben wir hier.
var { Services } = ChromeUtils.import(
"resource://gre/modules/Services.jsm"
);
var { MsgHdrToMimeMessage } = ChromeUtils.import(
"resource:///modules/gloda/MimeMessage.jsm"
);
var AllowHtmlTempApi = class extends ExtensionCommon.ExtensionAPI {
getAPI(context) {
return {
AllowHtmlTempApi: {
async checkMailForHtmlpart(messageId, optionsDebug) {
if (optionsDebug)
console.debug("AHT: run checkMailForHtmlpart ----------------");
let ahtMsgHdr = context.extension.messageManager.get(messageId);
// let ahtMsgHdr = gFolderDisplay.selectedMessage;
// First check MsgHdr without decrypting to prevent an additional passphrase dialog in case of PGP/MIME
let aMimeMsg = await new Promise(resolve => {
MsgHdrToMimeMessage(
ahtMsgHdr,
null,
(aMsgHdr, aMimeMsg) => resolve(aMimeMsg),
true,
{
examineEncryptedParts: false
}
);
})
// multipart/encrypted enables the button for encrypted PGP/MIME messages
// in this case we don't check for HTML, because the check seems not to be possible for PGP/MIME
if (aMimeMsg.prettyString().search("multipart/encrypted") != -1) {
if (optionsDebug)
console.debug("AHT: message is PGP/MIME multipart/encrypted");
return true;
// enableUiElements(tabId, optionsDebug);
} else {
// search for 'Body: text/html' in MIME parts,
// it seems this is only working if messages are downloaded for offline reading?
let aMimeMsg = await new Promise(resolve => {
MsgHdrToMimeMessage(
ahtMsgHdr,
null,
(aMsgHdr, aMimeMsg) => resolve(aMimeMsg),
true,
{
examineEncryptedParts: true
}
);
})
if (optionsDebug) {
console.debug("AHT: Check for html part ----------------");
console.debug("AHT: Body: text/html " + aMimeMsg.prettyString().search("Body: text/html"));
console.debug("AHT: text/html " + aMimeMsg.prettyString().search("text/html"));
console.debug("AHT: Body: plain/html " + aMimeMsg.prettyString().search("Body: plain/html"));
console.debug("AHT: plain/html " + aMimeMsg.prettyString().search("plain/html"));
console.debug("AHT: multipart/alternative " + aMimeMsg.prettyString().search("multipart/alternative"));
console.debug("AHT: multipart/signed " + aMimeMsg.prettyString().search("multipart/signed"));
console.debug("AHT: multipart/encrypted " + aMimeMsg.prettyString().search("multipart/encrypted"));
}
// 'Body: text/html' is found, enable ahtButtons
if (aMimeMsg.prettyString().search("Body: text/html") != -1) {
if (optionsDebug)
console.debug("AHT: message contains HTML body part");
return true;
// enableUiElements(tabId, optionsDebug);
}
// no 'Body: text/html', disable ahtButtons
else {
if (optionsDebug)
console.debug("AHT: no HTML body part");
return false;
// disableUiElements(tabId, optionsDebug);
}
}
}
}
}
}
};Kann ich dich dazu bewegen, diese Fragen (in Zukunft) im Matrix chat bzw. auf topic box zu stellen? Da alle die Antworten lesen können, ist da mein return of invest höher: https://developer.thunderbird.net/add-ons/community
Die Antwort: Du musst aus dem MsgHdrToMimeMessage callback ein Promise machen. Die Funktion returned bei dir nach dem Aufruf von MsgHdrToMimeMessage, und hat keinen Zugriff mehr auf den Wert aus dem Callback, das ausgeführt wird, wenn MsgHdrToMimeMessage fertig ist.
Siehe hier:
https://searchfox.org/comm-central/s…ages.js#383-395
Kannst du ein Bug auf bugzilla aufmachen mit deiner Anleitung und deinem Rproduzer-Add-on? Bugs kosten nix und wenn es keiner war, mach wir ihn wieder zu Aber ich muss die Sachen zentral bündeln, sonst verliere ich den Überblick.
Do you have an idea, what could be the reason?
It is notified here:
https://searchfox.org/comm-central/r…Overlay.js#3836
What happens if you set a breakpoint there? Is it ever reached? That seems to be the only place where this is fired.
In einem ähnlich gelagerten Fall hat sich gezeigt, das Outlook über EAS nur noch die Anmeldung mit Primär-Konten, und nicht mehr mit Alias-Konten erlaubt. Evtl. hilft das ja.