Welchen benutzt du (der nicht geht)?
Du hattest dieses Konstrukt mit mir geschaffen:
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.
Evtl schonmal releasen mit Hinweis auf feature-incomplete?
Das werde ich wohl so machen, um gleich auch mehr Feedback zu erhalten.
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
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:
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
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.
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.
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".
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
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.
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:
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:
wenn alle Fehler (Bugs) behoben sind
Also quasi nie... 
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
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:
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?
Hast Du probeweise mal ein neues Profil erstellt und dort ins "leere" Profil eine Erweiterung versucht zu installieren?
Ihr müsst die über die Jahre 3 verschiedenen Addons korrekt auseinander halten.
Der AttachmentExtractor von Stonehead ist auch für 115 verfügbar. Keine Ahnung, ob der inzwischen eine Feature für Filter hat.
Ich habe jetzt erstmal gemacht, was ich kann und stehe an diesem Entwicklungsstand:
Bitte schaue Dir an, was ich in der background.js hier geändert habe:
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?
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!
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
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.