Allow HTML Temp - Version 9.0 für Thunderbird 115

Quote from jobisoft

wahrscheinlich gibt es einen edge-case

Diesen gibt es - auch wenn man die eine Zeile zum Reload aller Tabs nicht auskommentiert. Öffne die Einstellungen des Add-ons und wähle mal für "Standard-Einstellung" → "Reiner Text" und für "Klick auf HTML zeigen" → "Original HTML".

Dann mache bei einer HTML-Mail einen wirklich schnellen 5fach-Klick auf den Button, oder ähnlich. Der Button fired dann mehrfach, noch bevor wieder auf die "Reiner Text"-Einstellung im Code-Ablauf zurück gewechselt wurde. Dadurch wird die Standard-Einstellung mit der ButtonPolicy überschrieben. Deshalb braucht man den "Block".

jobisoft

Dieser commit macht folgendes:

1.) Dein ignorePolicyChange wird so abgeändert, dass es die Tabs tatsächlich erst wieder reconnected, wenn AHT mit seinen messagePolicy updates fertig ist. Somit wird die per Klick mit HMTL geladene Mail nun auch erfolgreich angezeigt, wenn weitere AHT-Optionen aktiviert sind (Remote Content und/oder Inline Attachments). Es erübrigt sich auch mein comment out, welcher die Tabs ja dauerhaft von den default prefs entkoppelt hatte. Ich denke, dass müsste Dir so gefallen.

2.) Ich habe Deinen obigen Vorschlag so eingebaut, der die Button-Aktion blockiert, solange die erste Aktion nicht vollständig abgeschlossen ist. Deine Logik habe ich umgekehrt, weil es mir günstiger erschien. Ich denke eigentlich, dass man gar kein Array mit den verschiedenen Tabs nutzen müsste. Vermutlich würde ein globaler Block ausreichen oder sogar noch "sicherer" sein. Aber das mit dem Tab-Array scheint mir okay zu sein.

Somit steht jetzt nur noch das Wiedereinbauen der RemoteContentBar-Manipulation aus, wenn ich nicht irre. Wobei auch die Verwendung von setMsgHdrPropertyAndReload("remoteContentPolicy", kAllowRemoteContent); steht noch aus.

Mist, es gibt einen weiteren Bug durch die Funktion getButtonPolicy. Diese berücksichtigt nämlich nicht evtl. gedrückte Modifier Keys, sondern liest einfach stupide die Options von AHT aus. Das muss ich auch noch fixen.

Weiterer entdeckter Bug:

Wenn die Default Policy identisch mit der Button Policy ist, dann wir die Mail nicht neu geladen und zusätzlich versagt deswegen dann auch der onMessageDisplayed Listener, der zwingend den obigen Block auf false zurück stellen müsste und den Tab wieder zu den Prefs reconnecten müsste. An der Stelle rächt sich wahrscheinlich, dass aus meiner messageContentPolicy das Feature des (erzwungenen) Reload heraus gelöscht wurde.

Wann kommt es vor, dass man bei identischer Policy die Mail per Button neu laden will? Das ist notwendig, wenn die Mail per Button bspw. als HTML geladen wurde und man dann per Shift+Button wieder zu Reintext zurück will. In diesem Fall wäre die Default Policy = plaintext und die Button Policy plötzlich auch = plaintext (was im derzeitigen Stand auf GitLab schon für sich versagt, weil die Modifier Keys da vollkommen übergangen werden). Die Policy kann aber auch nahezu identisch sein, wenn man von HTML per Klick zu HTML+RemoteContent gelangen will. Da kommt es dann drauf an, wie genau man die Policies im Code vergleicht. Ich habe hier nämlich leider erst jetzt entdeckt, dass man Objekte gar nicht so einfach in JS vergleichen kann. jobisoft hatte für "isCurrentPolicy" ursprünglich auch nur den Teil "msgBodyAs" aus dem Objekt verglichen. Ich habe dies naiv und primitiv auf das ganze Objekt ausgeweitet, was beim Vergleich mittels "==" aber immer "false" ergibt. Je nach Situation in der Logik des Codes muss ich da also auch nochmal ran.

Mein alter Code erschien kompliziert, aber der war für die vielen möglichen Fallstricke durchaus ausgereift und strukturiert

Quote from Thunder

Mist, es gibt einen weiteren Bug durch die Funktion getButtonPolicy. Diese berücksichtigt nämlich nicht evtl. gedrückte Modifier Keys, sondern liest einfach stupide die Options von AHT aus. Das muss ich auch noch fixen.

Behoben

Quote from Thunder

Wenn die Default Policy identisch mit der Button Policy ist, dann wir die Mail nicht neu geladen und zusätzlich versagt deswegen dann auch der onMessageDisplayed Listener

Behoben

Somit bin ich jetzt erneut an einem Punkt, von dem ich glaube, dass jetzt "nur" noch die manipulierte remoteContentBar wieder eingebaut werden muss, und da brauche ich nun Hilfe.

Derzeitiger Stand:

Quote from jobisoft

Evtl schonmal releasen mit Hinweis auf feature-incomplete?

Das werde ich wohl so machen, um gleich auch mehr Feedback zu erhalten.

Quote from Thunder

die manipulierte remoteContentBar wieder eingebaut werden muss, und da brauche ich nun Hilfe.

Ich habe die Manipulation und den click listener einbauen können. Mein Code ist bestimmt verbesserungsfähig

Es bleibt noch ein Problem damit zu beheben. in der experimentellen API bekomme ich derzeit nicht mehr die korrekte tab.id mit Hilfe des Codes, den wir bisher verwendet hatten. Komischer Weise wird kein Fehler geworfen, sondern man bekommt jeweils eine falsche tab.id. Leider ist die tab.id aber zentral wichtig für die (weitere) Funktion des ganzen Add-on-Codes und bspw. den Reload des korrekten Tabs etc.

Quote from jobisoft

Welchen benutzt du (der nicht geht)?

Du hattest dieses Konstrukt mit mir geschaffen:

Quote from jobisoft

Ja, die gesamte mail3pane ist doch jetzt anders. Dein target ist nicht mehr in messenger.xhtml sondern in about:message. Ich denke du musst

let window = event.target.ownerGlobal.top;

nehmen, um an das tabmail zu kommen.

Wenn man sich auskennt, kann es so einfach sein - vielen Dank! Das war es.

Okay, Version 9.0.0 wartet jetzt auf ATN auf Überprüfung und Freigabe.

Wenn John aus Kanada zurück ist, kann man vielleicht noch die Art und Weise, wie der Remote Content erlaubt wird, verbessern. Außerdem werde ich noch ein paar Funktionen im Code konsolidieren, die momentan durch das neue Konzept auf 2 Dateien verteilt und vom Code her quasi doppelt sind (womit auch Fehler eher auftreten und schwieriger zu finden sein könnten).

Version 9.1.0 wartet auf Freigabe auf ATN.

Darin habe ich die Funktion zum Erlauben von Remote-Content wieder verbessert. Diese hat seit Thunderbird 115 (Add-on-Version 9.0) nicht mehr zufriedenstellend funktioniert. Die Probleme sollten nun behoben sein, sodass Remote-Content nun beim wiederholten Anzeigen einer Nachricht auch dauerhaft erlaubt bleibt (so war es bisher immer). Dies hilft auch, sodass beim Drucken einer Nachricht der Remote-Content nun auch wieder angezeigt/gedruckt wird. Und ebenfalls im Zusammenhang stand ein Problem bzw. Versagen, das bei der Benutzung des Kontextmenüs in der Remote-Content-Bar unter den Kopfzeilen der Nachricht auftreten konnte.

ggbsde

Du hast korrekt erkannt, dass ich NICHT in die Falle getappt bin, schon vorzeitig Manifest V3 zu verwenden. Danke Dir aber dennoch, dass Du aufmerksam darauf hinweisen wolltest.

Quote from Thunder

Version 9.1.0 wartet auf Freigabe auf ATN.

Diese Version ist nun auf ATN verfügbar.