Allow HTML Temp - Version 9.0 für Thunderbird 115

    Ich habe inzwischen aus dem abgespeckten "prove-of-concept" von jobisoft mal wieder "mein" Add-on gemacht. Die Optionen und Features sind fast alle wieder eingebaut.

    Es bleiben noch ein paar Dinge, die ich noch angehen muss.

    Zitat von jobisoft

    ich mache nix mit dem remote content popup (da würde ich übrigends nicht die pref manipulieren, sondern die msgHdr Eigenschaft der aktuellen Message, schau mal hier)

    Das habe ich bisher noch nicht verstanden, wie mir die verlinkte Funktion helfen soll, um das remote content popup für meine Bedürfnisse zu "tweaken".

    Zitat von jobisoft

    - default to plaintext für alle Nachrichten

    Hier zeigt sich leider eine Schwäche des neuen Konzepts, wenn ich nicht irre. Ich kann diesen Default per Optionen des Add-ons für die Anwender veränderbar (Original HTML, Vereinfachtes HTML oder Reintext) machen. Dies ist okay. Aber ich kann diesen Default aufgrund des Konzepts nicht synchron mit der eigentlichen Thunderbird-Einstellung machen, denn dazu müsste ich einen Listener etablieren, der dann wiederum ungewollt während des kurzzeitigen Umschaltens per API den Default schon wieder verändert.

    Zitat von Thunder

    Hier zeigt sich leider eine Schwäche des neuen Konzepts, wenn ich nicht irre.

    Es geht, wenn man etwas Kontroll-Logik verbaut. In dieser Version verbinde ich die Tabs nicht mehr mit dem core-pref-observer, wenn ich temporär HTML aktiviere (was den reload auslöst), sondern kontrolliere den reload jetzt direkt. Dadurch kann ich auch wieder alle tabs reloaded lassen, wenn die globale Pref geändert wird. Ich nutze dazu ein ahtStatus Objekt.

    Ich hab die Optionen hier auch wieder teilweise drin und es wird nicht mehr plaintext als default erzwungen, sondern was der user eingestellt hat. Der browser_action_button ist weiterhin nicht drin und das content popup ignoriere ich auch noch. Die Datei aht_functions.js lade ich nicht.

    Zitat von Thunder

    Das habe ich bisher noch nicht verstanden, wie mir die verlinkte Funktion helfen soll, um das remote content popup für meine Bedürfnisse zu "tweaken".

    Ich wusste nicht, dass du das content popup selber tweakst. Ich dachte, wenn der Bneutzer Shift drückt beim Klick auf den allow html button, dann soll einfach das popup nicht erscheinen und remote content automatisch geladen werden. Und dazu musst du keine globale Pref ändern, sondern nur im msghHdr das attribute setzen. Ist aber nur eine Idee, hat mit dem generellen Update für 115 nix zu tun.

    jobisoft und Thunder ich bedanke mich ganz herzlich bei euch beiden, es scheint ja so, dass AHT doch noch eine Chance hat auch ab Version 115* weiter zu laufen. :ziehtdenhut:

    Ich habe schon gebibbert, denn es ist für mich das wichtigste Addon überhaupt ist in TB.

    Mag sein, dass das die Download Zahlen dies nicht wieder wieder spiegeln, aber das liegt wohl eher daran, dass der Sicherheitsaspekt einfach immer noch zu wenigen bewusst ist.

    Ich habe in einem Testprofil auf jeden Fall die hier angebotene Version 8.3 ausprobiert, und es scheint super zu funktionieren. :thumbsup:

    Thunder : Hast du eigentlich ein github repo für AHT? Da wäre das gemeinsame Arbeiten einfacher. Hier ist Version 8.4:
    allow_html_temp-8.4.xpi

    Ich habe gemerkt, dass es invalide Button enable/disable Zustände geben kann, wenn die Optionen oder die Thunderbird-Einstellung im Menü geändert wird. Außerdem habe ich gemerkt, dass die event listener in update_ui.js teilweise gegen die event listener im background agieren. In v8.4 habe ich daher das Anzeigen der Message als den primären Aktivitätsvektor von AHT definiert und lade alle Nachrichten neu, wenn eine der möglichen Einstellungen geändert wird. Die event listener in update_ui.js habe ich deaktiviert bzw. ins background überführt. Wo die sind, ist primär egal, es sollte aber nicht 2 Orte dafür geben (mein Fehler).

    Außerdem:

    • Wenn der Button gedrückt wurde, ist die AHT Funktion ja getriggered worden und nochmaliges drücken hätte keinen Effekt mehr -> Ist jetzt einfach disabled. Ich vermute, das war früher auch so, ist aber durch das neue Konzept abhanden gekommen.
    • Wenn das Drücken des Buttons generell keinen Effekt hat, weil die aktuelle Einstellung (z.B. Plaintext) die gleiche ist wie die Button-Einstellung (ebenfalls Plaintext), dann ist der Button ebenfalls disabled.
    Zitat von jobisoft

    Hast du eigentlich ein github repo für AHT? Da wäre das gemeinsame Arbeiten einfacher.

    Es gibt das GitLab-Repo:

    Files · Thunderbird_Supernova · ThunderbirdMailDE / Allow HTML Temp · GitLab
    [Thunderbird Add-on] Allows to have HTML temporarily allowed in the currently displayed message by only one click. When switching to another message, it'll be…
    gitlab.com

    Dort habe ich Deine Version 8.2 mit den Optionen wieder verschmolzen. Ich hatte die Programm-Logik weitgehend in der aht_functions.js statt backgroudn.js belassen.

    Zitat von jobisoft

    Hier ist Version 8.4:

    Du hast in dieser Version die Logik für den browserActionButton drin gelassen. Der ist ja eigentlich obsolet und ich hatte diesen in meinem Code gestern schon raus geschmissen, sodass aus der update_ui.js auch viel Code raus fliegen konnte, der sich speziell um den browserActionButton beim Wechsel des Fokus zwischen Ordnern und Mails gekümmert hatte. Ich werfe dies jetzt aus dem Code Deiner 8.4 auch wieder raus und lade derzeit die Sachen auch wieder auf GitLab hoch.

    jobisoft

    1.) Sehe ich es richtig, dass die Version 8.4 die Optionen für externe Inhalte und für Grafiken inline anzeigen ignoriert?

    2.) Zusätzlich werden in 8.4 die "modifier keys" noch ignoriert

    3.) Durch das deaktivieren des Buttons nach dessen Nutzung wird ein Feature unmöglich, womit manche Anwender gerne mittels "Shift + Click" wieder zurück zu Reintext konnten.

    Ich selbst sitze gerade noch an update_ui.js und an background.js, wo ich schaue, was Du wie umgebaut hast. In aht_functions.js war halt die (aus Deiner Sicht) komplizierte Logik für die Modifier Keys etc. drin.

    Ich bin jetzt ein wenig hin und her gerissen, ob ich das jetzt mal weiter mergen soll, oder ob Du gerade weiter damit beschäftigt bist ;-)

    ne, ich mache gerade was anderes.:-)

    Die registerlistener funktion in update_ui hatte ich wieder auf den ursprünglichen Inhalt zurückgeführt, aber den Aufruf auskommentiert. Ich wollte das diff gegenüber der 8.1.5 so klein wie möglich halten.

    Ich würde an deiner Stelle glaube ich nur das Prinzip meine geänderte Logik übernehmen, aber nicht ganze Dateien von 8.4 1-zu-1 kopieren. Das hilft auch den code zu verstehen:-)

    Wenn du nicht weiterkommt, dann sag bescheid und ich probiere dann einen MergeRequest gegen dein Repo.

    Ich bin schon sehr weit - im Grunde fehlt jetzt nur noch Code aus Deiner background.js, welchen ich um meine Logiken noch erweitern muss. Vermutlich macht es Sinn, wenn Du jetzt erstmal abwartest, bis ich mich wieder bemerkbar mache. Ich habe bestimmt noch nicht alles verstanden, habe aber dennoch anhand der Diffs weitgehend verstanden, was Deine Logik jetzt macht, denke ich.

    Danke an Dich!

    jobisoft

    Ich habe jetzt erstmal gemacht, was ich kann und stehe an diesem Entwicklungsstand:

    dev-step-2023-08-10 · Tags · ThunderbirdMailDE / Allow HTML Temp · GitLab
    [Thunderbird Add-on] Allows to have HTML temporarily allowed in the currently displayed message by only one click. When switching to another message, it'll be…
    gitlab.com

    Bitte schaue Dir an, was ich in der background.js hier geändert habe:

    re-implement the logic from aht_functions.js again - not completely working (4f379bfb) · Commits · ThunderbirdMailDE / Allow HTML Temp · GitLab
    [Thunderbird Add-on] Allows to have HTML temporarily allowed in the currently displayed message by only one click. When switching to another message, it'll be…
    gitlab.com

    Die background.js nutzt jetzt wieder die Logik in aht_functions.js. Dies hat zur Folge, dass in der messageContentAPI bei Bedarf auch die Prefs für disableRemoteContent und/oder attachmentsInline geändert werden, um die Optionen des Add-ons komplett zu berücksichtigen. Auch die modifier keys werden somit berücksichtigt, die ebenfalls die pref für disableRemoteContent umstellen können. Daraus ergibt sich nun das Problem, dass der onChanged listener aus der API mehrfach fired, wodurch Deine Logik der ignorePolicyChange versagt.

    Hast Du dazu eine Idee?

    Zitat von Thunder

    Daraus ergibt sich nun das Problem, dass der onChanged listener aus der API mehrfach fired, wodurch Deine Logik der ignorePolicyChange versagt.

    Ich kann dies ganz simpel vermeiden, wenn man darauf verzichtet alle offenen Mails automatisch neu zu laden, wenn die Einstellungen geändert werden. Dazu würde ich ganz simpel gegenüber dem letzten Stand vom 10.8. auf GitLab folgende Zeile auskommentieren:

    Code
      if (ahtStatus.ignorePolicyChange) {
    ahtStatus = {
      // reloadAllTabs: true
    }
    return;
  }

    Dann bliebe jetzt nur noch der Wunsch, dass ich in der remoteContentBar im Kontextmenü die Funktion zum Erlauben des remote contents wieder so anpassen kann, dass dabei die Mail passend zur Einstellung von AHT geladen wird, weshalb ich ja bis AHT 8.1.5 den Menüpunkt per experimenteller API manipuliert hatte und den Click auf den Menüpunkt abgefangen hatte. Wie soll mir dabei das Folgende helfen?

    msgHdrView.js - mozsearch

    Zitat von Thunder

    Wie soll mir dabei das Folgende helfen?

    Ahhhhhhh, okay, lesen hilft. Dein Vorschlag ist gar kein Ersatz für die eigentliche Manipulation der remoteContentBar. Du hast nur vorgeschlagen, dass die dann aufgerufene Funktion statt der prefs dann den Teil aus der genannten Funktion aufrufen soll. Okay, das probiere ich so einzubauen. Du kannst mir also zumindest nochmal einen Tag geben, bevor Du Dich womöglich selbst nochmals bemühst ;-)

    jobisoft

    Ich muss leider doch Deine Hilfe für die Manipulation der RemoteContentBar in Anspruch nehmen. Und auch das Einbauen von setMsgHdrPropertyAndReload("remoteContentPolicy", kAllowRemoteContent); bekomme ich alleine nicht hin.

    Dieser Stand auf GitLab funktioniert aus meiner Sicht wie gewünscht, aber noch ohne die beiden zuvor genannten Dinge:

    dev-step-2023-08-17 · Tags · ThunderbirdMailDE / Allow HTML Temp · GitLab
    [Thunderbird Add-on] Allows to have HTML temporarily allowed in the currently displayed message by only one click. When switching to another message, it'll be…
    gitlab.com

    Hier kommt der Code mit den wieder eingebauten Code-Zeilen aus dem "alten" Add-on, die für die RemoteContentBar-Manipulation und den Click-Listener zuständig waren. Leider funktioniert der Code so noch nicht:

    Re-implement old code lines for RemoteContentBar manipulation - not working yet (faf468ba) · Commits · ThunderbirdMailDE / Allow HTML Temp · GitLab
    [Thunderbird Add-on] Allows to have HTML temporarily allowed in the currently displayed message by only one click. When switching to another message, it'll be…
    gitlab.com

    Ich bin nur Anwender und kann hier leider überhaupt nichts zur Problemlösung beitragen. Da aber AHT mein wichtigstes Addon ist, habe ich diesen Thread verfolgt und gesehen, dass die Addon-Entwicklung durchaus nichttrivial und ganz schön mühsam ist. Das war mir in diesem Ausmaß bisher gar nicht so richtig bewusst. Deswegen an dieser Stelle mal ganz herzlichen Dank an Thunder, jobisoft und alle anderen Addon-Entwickler, die uns Anwendern das digitale Leben erleichtern! :thumbup: :ziehtdenhut:

    Ich muss leider feststellen, dass die bisherigen Varianten und Entwicklungsschritte für das "neue" Add-on leider alle noch das Problem haben, dass man mit schnellem Mehrfach-Click auf den Button (der sich etwas verzögert deaktiviert) ein alten Problem wieder hervorbringen: Man kann mit schnellem Mehrfachklick die Einstellung des Programms "zerstören". Ich hatte in AHT bis 8.1.5 eine Block-Logik drin, die das seit langer Zeit verhindert hat. Diese Logik fehlt momentan, und ich muss probieren diese wieder einzubauen, womit ich jobisofts Programm-Logik nochmal über den Haufen werfen muss.

    Lass uns zuerst das Button-mehrfach-Klicken Problem lösen. Du sagst, es trifft auch in diesem "guten aber nicht vollständigen" Entwicklungsstand auf? https://gitlab.com/ThunderbirdMai…step-2023-08-17

    Ich kann das Problem zunächst nicht nachstellen, aber wahrscheinlich gibt es einen edge-case, den ich noch nicht erwischt habe. Ich würde vorschlagen erstmal mit dem "guten aber nicht vollständigen" Entwicklungsstand weiterzumachen:

    * die Aufrufe zum disable des Buttons erfolgen sehr spät: Maßnahme #1 ist ein acceptButtonClicks flag, das gesetzt werden muss, bevor der Button was tut (egal ob er enabled oder disabled ist)
    * ich würde das flag am Ende des onMessageDisplayed listeners auf true setzen (unabhängig vom Button disable/enable status).
    * Ich würde das flag in einer globalen Map (tabId->status) speichern und es auch auf false setzen, bevor wir den reload triggern (eigentlich direkt am Anfanf des onClicked listeners), sodass wir ganz klar die Funktion des Buttons in den problematischen Zeiträumen deaktivieren.
    * im onClicked listener prüfst du das flag und machst ein early exit, wenn es nicht existiert oder flase ist: if (!acceptButtonClicks.get(tab.id)) { return; } funktioniert in beiden Fällen.

    Das hat zur Folge, dass der User bei diesen edge-cases zwar u.U. einen aktiven Button hat (der durch das timing issue noch nicht deaktiviert wurde), aber der Klick wird ignoriert. Wie klingt das?

    Zitat von Thunder

    Man kann mit schnellem Mehrfachklick die Einstellung des Programms "zerstören".

    Zitat von jobisoft

    Ich kann das Problem zunächst nicht nachstellen, aber wahrscheinlich gibt es einen edge-case,

    Hallo, als Feedback aus dem "Volk". ;)

    Die 8.4 aus #26 stellt sich bei mir so dar:

    einfacher Klick schaltet temporär auf HTML und Button wird blass, bei nächster Mail wieder Reintext und Button bereit.

    Mit schnellem Doppelklick umschalten auf HTML und Button wird blass, bleibt auch bei weiteren Mails blass

    und zeigt entsprechend in HTML. Rückstellung nur über Ansicht -> Nachrichteninhalt -> Reintext.

    Gruß, Bastler
    ------------------------------------------------------------------------------------------------------------
    Eine Rückmeldung zum Gelingen oder nicht, kann auch für andere nützlich sein.

    Zitat von jobisoft

    Wie klingt das?

    Klingt gut. Im Prinzip hatte ich sowas auf altmodisch ja in meinen bisherigen Versionen in der aht_functions.js mit drin.

    Das Deaktivieren des Buttons ist auf den ersten Blick ein tolles Feature, aber es gibt eben auch User, die im Nachgang wieder zu "Reintext" oder Anderem zurück wollen (und dies per Modifier Key + Klick auf den Button bisher auch konnten). Denen macht man das dann (per Button) unmöglich. Deshalb bin ich bei diesem Feature hin und her gerissen.

    Deine Hilfe ist sehr willkommen - Danke