Beiträge von jobisoft

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.

Zitat von Thunder

Danke jobisoft

Immer gern.

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.

Zitat von Schorsch05

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?

Zitat von ks-tb

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.

Log in to Bugzilla

Zitat von Thunder

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.

Dass es gar nicht geht, kann ich derzeit weder bei outlook.de noch bei iCloud bestätigen. iCloud ist ja auch DAV und nicht EAS.

iCloud: Evtl. hast du dein App-Passwort bei iCloud gelöscht (Apple verlangt da ja ein App-spezifisches Passwort für TbSync)?

Outlook.de: Evtl. ist deine generierte Device-ID verbrannt (too many failed attempst?) Das Konto in TbSync komplett löschen und neu einrichten hilft nicht?

Das ist insoweit temporär, als dass Add-on Entwickler ihre Add-ons in echte WebExtensions konvertieren (der erste und einfachste Schritt ist oft sogar der Options-Dialog). Solange sie das nicht machen, ist Ihr Options-Button nicht "echt". Es gibt keinen einfachen Weg in diesem Fall an die Url der Options-Seite zu kommen, du musst den Quellcode der Add-ons parsen:

1. Extrahiere Manifest für jedes Add-on: https://searchfox.org/comm-central/s…sExtra.js#76-89
2. Gucke data.manifest.background.scripts an ( = array of background script urls).
3. Lese jede background Datei ein: let content = await fetchFile(<url-from-scripts-array>)

    fetchFile: function (aURL, returnType = "Array") {
        return new Promise((resolve, reject) => {
            let uri = Services.io.newURI(aURL);
            let channel = Services.io.newChannelFromURI(uri,
                                 null,
                                 Services.scriptSecurityManager.getSystemPrincipal(),
                                 null,
                                 Components.interfaces.nsILoadInfo.SEC_REQUIRE_SAME_ORIGIN_INHERITS_SEC_CONTEXT,
                                 Components.interfaces.nsIContentPolicy.TYPE_OTHER);

            NetUtil.asyncFetch(channel, (inputStream, status) => {
                if (!Components.isSuccessCode(status)) {
                    reject(status);
                    return;
                }

                try {
                    let data = NetUtil.readInputStreamToString(inputStream, inputStream.available());
                    if (returnType == "Array") {
                        resolve(data.replace("\r","").split("\n"))
                    } else {
                        resolve(data);
                    }
                } catch (ex) {
                    reject(ex);
                }
            });
        });
    },

4. Suche in jeder Background Datei nach registerOptionsPage(<url-to-options-page>).

Wenn das add-on kein data.manifest.background.scripts hat, musst du nach data.manifest.background.page ( = html page url) gucken und die html seite nach script tags parsen und so den scripts array selber zusammenbauen.

Ich kann nicht wirklich was zu outlook sagen, scheint als würden die an Ihrer Anbindung Änderungen vornehmen. Autodiscover scheint auch nicht mehr zu gehen. Ich hab mein Konto manuell eingerichtet und als Server "eas.outlook.com" eingetragen. Evtl. hilft das ja.

Hast du früher mal mit dem SOGoConnector synchronisiert? Das TB Add-on hatte einen bug und hat das flag gesetzt und dann zurück auf die Server gesynct.

Mach mal einen Export deiner Kontakte direkt im Owncloud WebInterface. Da müssten die Einträge auftauchen.