Zurücksetzen der Thunderbird-eigenen Prefs auf deren Standardwerte - ist gar nicht notwendig

  • Hallo Leute!


    Ich möchte dieses Thema hier mal eröffnen und nutzen, um Euch nochmals über die Funktion von Allow HTML Temp (im Folgenden: AHT) aufzuklären.


    Der Wunsch von jobisoft hat mir gezeigt, dass vermutlich viele Anwender das Prinzip von AHT nur bedingt verstehen, denn ein Zurücksetzen von Thunderbirds eigenen Prefs ist aus meiner Sicht gar nicht notwendig:

    Quote
    Code
    *********
    John Bieling wrote:
    
    With your next version, could you return to a standard pref configuration, when your add-on is shutting down?
    
    *********


    Die Optionen meines Add-ons:



    Die Standard-Einstellung wechselt den HTML-Modus ganz genau so, wie es auch Thunderbirds eigener Menüpunkt Ansicht → Nachrichteninhalt macht. Daran gibt es nichts zurückzusetzen.



    Klick auf "HTML zeigen" ist ein Teil der Einstellung für die Funktion des Buttons des Add-ons. Wenn der Button genutzt wird, wird die vorherige HTML-Einstellung (also die notwendigen Prefs dazu) kurz zwischengespeichert und sobald die Nachricht dann mit der gewünschten Einstellung angezeigt wurde (dies wird mit einem "event listener" erkannt), werden die Prefs aus dem Zwischenspeicher im Hintergrund sofort wieder hergestellt. Daran gibt es also später auch nichts mehr zurückzusetzen.



    Externe Inhalte in Nachrichten global erlauben ist die identische Einstellung, die man in Thunderbirds Einstellungen-Dialog findet:



    Genau diese Einstellung wird also umgeschaltet. Daran gibt es auch nichts zurückzusetzen. Der Anwender kann dies jederzeit in Thunderbirds Einstellungen machen.


    Bei Klick auf "HTML zeigen" für die eine Nachricht erlauben ist wieder ein temporäres aktivieren der Pref, deren vorheriger Zustand zwischengespeichert wird und dann sofort wieder hergestellt wird.



    Anhänge immer eingebunden anzeigen (nicht empfohlen) ist wieder eine Pref von Thunderbird selbst, die man in Thunderbird über das Menü Ansicht → Anhänge eingebunden anzeigen ebenfalls identisch schalten kann. Auch daran gibt es eigentlich nichts zurückzusetzen.


    Bei Klick auf "HTML zeigen" temporär eingebunden anzeigen ist wieder ein temporäres aktivieren der Pref, deren vorheriger Zustand zwischengespeichert wird und dann sofort wieder hergestellt wird.


    Später bei der Deinstallation meines Add-ons gibt es also aus meiner Sicht keine Thunderbird-eigenen Prefs, welche dann noch zurückgesetzt werden könnten oder müssten. Die kurzzeitig ("temporär") manipulierten Prefs wurden alle immer wieder sofort zurück gesetzt. Die restlichen Prefs sind letztlich Einstellungen, die das Add-on wegen des thematischen Zusammenhangs in seinem Optionen-Dialog mit anbietet. Diese Einstellungen sind aber ganz normal über die Benutzeroberfläche des Thunderbird sowieso vorhanden und können dort auch jederzeit (egal ob mit oder ohne Add-on) umgeschaltet werden. Das Add-on berücksichtigt dies auch jederzeit. Würde man bei der Deinstallation des Add-ons nun noch etwas zurücksetzen wollen, muss die Frage gestellt werden, was man dann überhaupt noch zurücksetzen will. Der Anwender könnte nämlich während der Nutzungszeit des Add-ons über Thunderbirds eigene Benutzeroberfläche diese Einstellung verändert haben. Die sollen dann gar nicht unerwartet zurückgesetzt werden.


    Alle Einstellungen, die das Add-on selbst betreffen sind ab Version 8 des Add-ons im "local storage" abgelegt und werden bei Deinstallation des Add-ons entfernt, so wie es eben für WebExtensions üblich ist. So lange das Add-on keine Fehlfunktionen hat, hinterlässt es auch keine durcheinander gebrachten Prefs des Thunderbird. Und selbst wenn dies (für den HTML-Modus) passieren würde, dann muss der Anwender nur einmal über Ansicht → Nachrichteninhalt umschalten und alles ist wieder durch Thunderbird selbst korrigiert, da dieser dabei die Prefs selbst (dann korrekt) überschreiben würde.


    Ich hoffe hiermit etwas Licht ins Dunkel zu bringen. Ihr könnt aber gerne auch fragen. Ich kann im Zweifelsfall auch im Code die Dinge erklären.

  • Im gelben "Doorhanger" mit dem Kontextmenü für externe Inhalte ("remote content") wird vom Add-on das oncommand per experimenteller API überschrieben (mehr oder minder entfernt) und mittels eines eventlisteners abgefangen, um an der Stelle bei installiertem Add-on nach dem Klick auf "HTML zeigen" dann auch das vom Anwender erwartete Verhalten beim Klick auf "Externe Inhalte in dieser Nachricht anzeigen" zu bewirken (es muss dann nämlich für den Reload mit externen Inhalten nochmals temporär HTML erlaubt werden).




    Dieses oncommand wird beim Shutdown des Add-ons in der experimentellen API zurück gesetzt:


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

  • Daher die Bitte: Speichere den Zustand aller prefs die du dauerhaft änderst und reverte auf diesen Zustand, wenn den add-on runterfährt.

    Das kann ich prinzipiell gerne machen, aber:

    • Was ist, wenn andere Add-ons ebenfalls die gleichen Prefs nutzen und/oder verändern? Denen pfusche ich dann unerwartet ins Handwerk.
    • Was ist, wenn der Benutzer bewusst die Pref im Add-on oder in Thunderbirds eigener UI verändert hat? Dann überschreibe ich auch wieder dessen gewählte Einstellung.

    Technisch könnte ich theoretisch bei der Installation des Add-ons die relevanten Prefs im local storage hinterlegen und von dort bei der Deinstallation/Deaktivierung wieder in die Prefs zurück schreiben. Aber die Fragen bleiben dabei offen und problematisch. Ich könnte sogar per Listener Änderungen an den Prefs mitbekommen, um diese für später auch zu berücksichtigen. Nur leider wird dies scheitern, da der Listener ja gar nicht unterscheiden kann, ob in den Optionen des Add-ons umgeschaltet wurde oder in Thunderbirds Benutzeroberfläche.


    Immerhin "manipuliert" mein Add-on erstens nur zugängliche Prefs, und hinterlässt auch da nur Veränderungen, wenn diese mehr oder minder bewusst vom Anwender im Dialog vorgenommen wurden. Alles was im Hintergrund temporär abläuft, hinterlässt keine Veränderungen an den Prefs.


    Ich hatte außerdem extra den "Reset" Button im Dialog eingebaut, um zu sicheren Einstellungen zurückkehren zu können. Dies dann aber wenigstens bewusst für den Anwender. Bei diesem Reset müsste ich dann halt "Anhänge immer eingebunden anzeigen (nicht empfohlen)" eigentlich aktivieren, da dies Thunderbirds default ist. Momentan (Version 8.0a5 des Add-ons) wird die Option beim Reset deaktiviert.


    Edit:

    Was man natürlich machen kann: Bei der Deinstallation müsste ein Dialog alle Einstellungen beim Anwender erfragen, wie er diese denn gerne haben möchte.

  • Ich baue es jetzt so ein, wenn es klappt:

    1. Im Optionen-Dialog wird es zwei Reset Buttons geben: einer zu Default, und einer zu Recommended
    2. Beim Shutdown wird ein Dialog fragen, ob zu Thunderbirds defaults zurückgekehrt werden soll (HTML-Modus, Inline-Attachments und Remote Content)


    Schritt 1 ist erledigt:


  • 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/…ensions/API/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.

  • Deine Lösung mag funktionieren, auch wenn ich momentan erstmal nur eine grobe Vorstellung von "original" und "current" habe.


    Wenn wir jetzt aber mal die Realität betrachten, dann ist es doch so, dass circa 10.000 Anwender (oder Installationen) das Add-on verwenden. Diese Zahl hat sich seit langer Zeit kaum verändert. Aus rein technischer, formaler, Support und vielleicht auch "sportlicher" Sicht, kann man das alles einbauen. Es wird aber der stabilen User-Basis von rund 10.000 gar nichts bringen, da deren "original" Werte aus Add-on-Sicht gar nicht mehr zu eruieren sind.

    Ne andere Lösung fällt mir derzeit nicht ein.

    Mir schon...

    1. siehe oben: Dialog beim Deaktivieren/Deinstallieren des Add-ons

    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.

  • * 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/…ensions/API/notifications) dass AHT die Pref gelockt hat.

    Ich verstehe gerade nicht, wann dieses Szenario eintreten soll.


    original = vor Add-on-Installation

    current = vom User gewählte Einstellung - und da müsste ich dann unterscheiden, ob in Thunderbird UI gewählt (soll persistent bleiben) oder in Add-on-Dialog gewählt (soll später auf original zurück gestellt werden)

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

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

    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.


    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.


    jobisoft Übrigens hatte ich Deine Anfrage im AHT-API Bug gesehen. Wenn nicht dieses Thema hier jetzt "neu" aufgekommen wäre, hätte ich vielleicht heute schon was dazu für Dich gemacht. Jedenfalls habe ich den "need-info" request im Kopf und komme darauf zurück.

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

  • Übrigens habe ich schon seit längerer Zeit bei meinen Add-ons die Prefs dokumentiert. Das Dilemma ist allerdings, dass inzwischen mit ATN, GibLab und hier auf TMDE gleich drei Orte existieren, an denen ich Informationen zu den Add-ons bereitstellen könnte/müsste - und dies dann auch noch mit unterschiedlichen "Markup"-Systemen.


    Hier mal ein Beispiel:

    Allow HTML Temp - Add-on to allow HTML (only) temporarily - Thunderbird Mail DE