Verändertes Verhalten seitens Thunderbird bei Änderungen per about:config bzw. per Prefs-API

    Hallo Leute!

    Seit einigen Beta-Versionen hat sich das Verhalten von Thunderbird nach dem 102er-Release geändert. Wenn in den momentanen Beta-/Entwickler-Versionen per about:config eine Änderung gemacht wird, führt dies dazu, dass alle geöffneten Mails sofort automatisch neu geladen und angezeigt werden. Ich überblicke bisher nicht, ob dies alle oder nur bestimmte Prefs betrifft. Aus dem Bauch heraus halte ich das Verhalten aber für bedenklich.

    Eine erste Konsequenz des Verhaltens ist, dass mein Add-on "Allow HTML Temp" aus gleich zwei Gründen nicht mehr weiter möglich sein wird:

    1. Das kurzzeitige Aktivieren von HTML per Prefs-API im Hintergrund führt direkt dazu, dass alle offenen Mails neu mit HTML geladen werden - also nicht nur die eine gewünschte Mail.

    2. Das sofortige Zurückschalten auf Reintext bzw. vereinfachtes HTML führt ebenso dazu, dass alle offenen Mails dann wieder neu geladen werden. Dadurch wird natürlich auch für die eine gewünschte Mail die HTML-Darstellung gleich wieder "versteckt".

    Ich wurde inzwischen informiert (Danke dafür), dass mein beobachtetes Verhalten des Thunderbird durch einen neu eingeführten Observer verursacht wird:

    aboutMessage.js - mozsearch

    Es führen also nicht pauschal alle Prefs, bei deren Änderung, zu einem Reload der geöffneten Nachrichten.

    jobisoft hat einen RFE-Bug erstellt (auch dafür ein Danke), um das Verhalten zu verändern und somit für mein Add-on wieder nutzbar zu machen.

    1829790 - Make "View Message Body as" a per-message option
    NEW (nobody) in Thunderbird - Message Reader UI. Last updated 2023-04-25.
    bugzilla.mozilla.org
    Quote from Thunder

    und somit für mein Add-on wieder nutzbar zu machen.

    Wobei ich da dann immer noch mehrere Hürden sehe. Das Add-on wird konzeptionell also vermutlich anders werden. Ich sehe das momentan so, dass es eher nur noch ein Button sein wird, der für die gerade angezeigt Mail das HTML (de-)aktivieren bzw. umschalten wird. Es wird sich dann also um eine Art "Shortcut" per Button handeln, so dass man nicht über das Menü im Bereich der Kopfzeilen gehen muss. Ich muss jetzt erst mal abwarten, ob und wie die Änderungen in Thunderbird selbst umgesetzt werden.

    Sieht leider so aus, als würde es für Thunderbird 115 / Supernova nichts mehr mit meinem Add-on. Die Basis dafür müsste einfach in Thunderbird geschaffen werden. Da der String-Freeze bereits abgelaufen ist, kann die notwendige Änderung innerhalb Thunderbirds eigentlich nicht mehr vorgenommen werden - jedenfalls nicht so, wie John das im zugehörigen Bug durchaus gut vorgeschlagen hat.

    "Allow HTML Temp" müsste zunächst für TB 115 angepasst werden, laut ATN ist es nur bis TB 111 kompatibel.

    Du meinst mailnews.display.prefer_plaintext, mailnews.display.disallow_mime_handlers, mailnews.display.html_as und mail.inline_attachments? Die verändert Dein Add-on alle, ist das nötig?

    Ich schlage vor, Du installierst Dir eine 115 beta, nennst omni.ja auf onmi.zip um und entpackst es. Dann kannst Du den JS-Code nach Belieben ändern, z.B. eine oder mehrere Prefs aus dem observer zu entfernen.

    Mein Ansatz war, eine zusätzliche Pref einzuführen, etwa mailnews.display.observe_html_as, und wenn diese false ist, mailnews.display.html_as nicht in den observer aufzunehmen. Wenn diese "kleine" Lösung nicht funktioniert, was Du mit wenig Aufwand probieren kannst, muss man auf den Bug warten. War auch nur ein Angebot, das in BB ein bisschen zu beschleunigen.

    1.) Die Inline-Attachments sind eine der Optionen des Add-ons, welche per Klick kurzzeitig aktiviert werden können.

    2.) Remote-Images sind ebenfalls eine der Optionen. Diese habe ich hier aber (oben) nicht aufgeführt, weil die zugehörige Option nicht in der referenzierten Datei/Liste per Observer seitens des Message Viewers observed wird.

    3.) Die drei genannten mailnews.display Prefs gehören gemeinsam zum "Schalter" des HMTL-Modus, weil bspw. beim "Vereinfachten HTML" nicht alleine der *.html_as ausreichen würde.

    Ich habe mich schon lange nicht mehr gefragt, ob diese Kombination so notwendig ist, aber meiner Erinnerung nach war und ist dies so. Dazu trägt auch bei, dass es theoretisch noch andere Kombinationen der 3 Prefs geben könnte, welche man nicht vorhersehen kann. Man muss/musste sicher gehen, dass tatsächlich die passende 3er-Kombination für meine Zwecke aktiviert und dann sofort wieder zurück gestellt wird.