Beiträge von Thunder

Man kann Thunderbird per Konfig-Editor umstellen. Bin unterwegs, daher gerade keinen passenden Link.

Ich habe LiveMail nicht vor Augen. Was genau willst Du sehen können?

Selektiere mit der Maus doch bitte mal eine oder auch mehrere Mails im Thread-Pane. Dann drücke die Taste M und schau, was passiert.

Voransicht: aus

Automatik: an

Mail in Tab/Fenster öffnen → Fett ist weg.

Wenn Du die Voransicht in Thunderbird aktiviert hast, dann ist dies faktisch ein Öffnen der Mail, weil es in Wahrheit keine "Voransicht" ist, sondern ein vollständiges Laden der Mail.

Du hast also nur die Wahl zwischen der Automatik oder dem manuellen als gelesen markieren per Taste M.

Streng genommen bedeutet der Fettdruck, dass die E-Mail "ungelesen" ist. Dies wird von "neu" unterschieden. Neu ist eine E-Mail nur innerhalb der "Sitzung" in Thunderbird und solange sie noch ungelesen ist. Sobald Thunderbird neu gestartet wird, sind die Mails dann nicht mehr "neu", sondern bestenfalls noch "ungelesen". "Neue" E-Mails zeigen ein gelbes Sternchen vor dem Betreff (nicht zu verwechseln mit dem anderen gelben Stern, der für "markiert" steht).

Deaktiviere in den Einstellungen die Automatik, dann werden Mails erst als gelesen markiert (also der Fettdruck verschwindet), wenn diese von Dir manuell als gelesen markiert werden.

Thema

Update-URL zeigt auf Thunderbird-Updates - was passiert beim Update?

Moin!

Ich habe mir aus Interesse gerade mal ein paar Dinge im Konfig-Editor des Betterbird angeschaut. Die meisten URLs zeigen weiterhin auf die ursprünglichen URLs des zugrundeliegenden Thunderbird.

Aus Datenschutz-Sicht sind also irgendwie sowohl MZLA als auch Betterbird "im Boot". Zu Betterbird zeigt derzeit die URL für die Startseite und die Rückmeldung von Version, OS etc.

Bei dieser Durchsicht im Konfig-Editor ist mir aufgefallen, dass die Update-URLs weiterhin zu thunderbird.net leiten und…

Thunder

6. Oktober 2021 um 12:08

Betterbird hat nicht die (personellen und technischen und finanziellen) Möglichkeiten, um die Update-Infrastruktur betreiben zu können.

Hmmm, ich hatte den Eindruck, dass er dann wieder in der background.js nicht wartet ...

... aber Du hast natürlich Recht. Es funktioniert jetzt auch mit der einfachen Variante.

Du bist mein Held

Dein Code in meine implementation.js und folgendes in der background.js (bzw. in zusätzlicher JS-Datei), um meine API aufzurufen:

  let hasHtmlMimePart = await new Promise(resolve => {
    resolve ( browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug) )
  });

  if(options.debug)
    console.debug("AHT: checkMailForHtmlpart returns: " + hasHtmlMimePart);

  if(hasHtmlMimePart) {
    browser.messageDisplayAction.enable(tab.id);
    browser.browserAction.enable(tab.id);
  }

Damit funktioniert es genau so wie es soll.

Tausend Dank!

Zitat von jobisoft

Da alle die Antworten lesen können, ist da mein return of invest höher

Sobald ich mein Problem und den Transfer komplett verstanden und erfolgreich umgesetzt habe, werde ich es für alle auf Topicbox in einem neuen Thema beschreiben / erklären. Und in Zukunft bin ich natürlich bereit dazu. Es ist nur schon schwer genug in der Muttersprache sein technisches Problem zu erklären .

Ein paar Fragen:

1. Wie erreiche ich, dass der Code in background.js nach dem Aufruf meiner API erst ausgeführt wird, wenn ich von meiner API ein true oder false zurück bekommen habe? Ich habe es beispielsweise mit let hasHtmlMimePart = await browser.AllowHtmlTempApi.... probiert und dann anschließend eine if-Abfrage gemacht. Aber der Code anschließend wird immer schon zu früh ausgeführt.
2. Wie bekomme ich überhaupt aus (m)einer Experiment API ein simples boolean true/false zurück gemeldet an meinen Code im Bereich der background.js?

  await browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug);

  if(options.debug)
    console.debug("AHT: enableUiElements");
  browser.messageDisplayAction.enable(tab.id);
  browser.browserAction.enable(tab.id);

[
  {
    "namespace": "AllowHtmlTempApi",
    "functions": [
      {
        "name": "checkMailForHtmlpart",
        "type": "function",
        "description": "Checks selected message for a HTML MIME part.",
        "async": true,
        "parameters": [
          {
            "name": "messageId",
            "type": "integer",
            "description": "MailExtension message.id"
          },
          {
            "name": "optionsDebug",
            "type": "boolean",
            "description": "MailExtension options.debug"
          }
        ]
      }
    ]
  }
]

var { Services } = ChromeUtils.import(
  "resource://gre/modules/Services.jsm"
);

var { MsgHdrToMimeMessage } = ChromeUtils.import(
  "resource:///modules/gloda/MimeMessage.jsm"
);

var AllowHtmlTempApi = class extends ExtensionCommon.ExtensionAPI {
  getAPI(context) {
    return {
      AllowHtmlTempApi: {
        async checkMailForHtmlpart(messageId, optionsDebug) {

          if(optionsDebug)
            console.debug("AHT: run checkMailForHtmlpart ----------------");
          let ahtMsgHdr = context.extension.messageManager.get(messageId);
          // let ahtMsgHdr = gFolderDisplay.selectedMessage;

          // First check MsgHdr without decrypting to prevent an additional passphrase dialog in case of PGP/MIME
          MsgHdrToMimeMessage(ahtMsgHdr, null, function(aMsgHdr, aMimeMsg) {
            // multipart/encrypted enables the button for encrypted PGP/MIME messages
            // in this case we don't check for HTML, because the check seems not to be possible for PGP/MIME
            if (aMimeMsg.prettyString().search("multipart/encrypted") != -1) {
              if(optionsDebug)
                console.debug("AHT: message is PGP/MIME multipart/encrypted");
              return true;
//            enableUiElements(tabId, optionsDebug);
            } else {
              // search for 'Body: text/html' in MIME parts,
              // it seems this is only working if messages are downloaded for offline reading?
              MsgHdrToMimeMessage(ahtMsgHdr, null, function(aMsgHdr, aMimeMsg) {
                if(optionsDebug){
                  console.debug("AHT: Check for html part ----------------");
                  console.debug("AHT: Body: text/html " + aMimeMsg.prettyString().search("Body: text/html"));
                  console.debug("AHT: text/html " + aMimeMsg.prettyString().search("text/html"));
                  console.debug("AHT: Body: plain/html " + aMimeMsg.prettyString().search("Body: plain/html"));
                  console.debug("AHT: plain/html " + aMimeMsg.prettyString().search("plain/html"));
                  console.debug("AHT: multipart/alternative " + aMimeMsg.prettyString().search("multipart/alternative"));
                  console.debug("AHT: multipart/signed " + aMimeMsg.prettyString().search("multipart/signed"));
                  console.debug("AHT: multipart/encrypted " + aMimeMsg.prettyString().search("multipart/encrypted"));
                }
                // 'Body: text/html' is found, enable ahtButtons
                if (aMimeMsg.prettyString().search("Body: text/html") != -1) {
                  if(optionsDebug)
                    console.debug("AHT: message contains HTML body part");
                  return true;
//                enableUiElements(tabId, optionsDebug);
                }
                // no 'Body: text/html', disable ahtButtons
                else {
                  if(optionsDebug)
                    console.debug("AHT: no HTML body part");
                  return false;
//                disableUiElements(tabId, optionsDebug);
                }
              }, true, {
                examineEncryptedParts: true
              }); // examineEncryptedParts=true is necessary for encrypted S/MIME messages
            }
          }, true, {
            examineEncryptedParts: false
          }); // examineEncryptedParts=false to prevent an additional passphrase dialog in case of PGP/MIME
        }
      }
    }
  }
};

Der Code in implementation.js funktioniert für sich gesehen korrekt. Und hatte mir im alten XUL-Addon dann sinngemäß den 3 auskommentierten Zeilen meine Buttons aktiviert bzw. deaktiviert. Hier im Code habe ich jetzt statt dessen return true bzw. return false eingesetzt, um dies letztlich an die background.js zurück zu bekommen.

Bug ist erstellt: https://bugzilla.mozilla.org/show_bug.cgi?id=1762427

Reproducer Add-on werde ich die Tage noch zur Verfügung stellen.

Die Link-Preview-Cards werden in Thunderbird beim "Verfassen" also beim Absender generiert und vermutlich als Teil der dann erzeugten HTML-Mail mit versendet. Beim Empfänger ist dafür überhaupt keine Verbindung notwendig - nur die Anzeige als "Original HMTL", denke ich. Jedenfalls verstehe ich die Beschreibung des Features für Thunderbird so.

jobisoft

Ich bin vermutlich über einen Bug gestolpert, der Auswirkungen auf browser.messageDisplay.onMessageDisplayed.addListener(async (tab, message) => { hat. Das event wird nicht für Mails in separaten Windows gefeuert, wenn sich eine Message Property (Junkstatus) ändert. Ursache ist wohl, dass die Message dabei im separaten Fenster gar nicht neu geladen bzw. angezeigt wird. Um dies zu reproduzieren:

Öffne eine HTML-Mail im Original-HTML-Modus im 3-pane-Window (den Preview). Öffne die identische Mail zusätzlich in einem separaten Window, sodass Du beides sehen kannst. Markiere nun die Mail im separaten Window als Junk.

Im 3-Pane-Window wird die Mail neu geladen und der Junk-Button (Main Toolbar und Message Header Toolbar) ändert korrekt seine Anzeige. Im separaten Window wird zwar die gelbe Leiste oben in der Mail eingeblendet, aber die Mail bleibt im originalen HTML angezeigt (wird also nicht neu geladen) und der Junk-Button bleibt unverändert "Junk". Mein Add-on wird dann folglich auch nicht (über die Änderung für das separate Window) informiert, was ich aber benötige.

Das event onMessageDisplayed.addListener(async (tab, message) gibt immer nur die tab.id des 3-pane-Window zurück - auch, wenn ich den Junk-Button im separaten Window benutzt habe, welches eine ganz andere tab.id hat. Das ist irgenwie auch logisch, da die Mail ja scheinbar nur im 3-pane neu geladen wird, aber nicht im separaten Window.

Zu Eurer Information:

Ich arbeite derzeit an einer neuen Version des Add-ons, die soweit möglich zu einer MailExtension mit Experiment-APIs umgeschrieben ist. Dabei mache ich derzeit gute Fortschritte, werde aber vermutlich im Verlauf Hilfe von jobisoft benötigen.

For both of you Tilo265 and wojtek , the Listener for event "MsgMsgDisplayed" is correctly registered by my addon code, but this (Thunderbird own) event seems never to be "fired", when message were displayed. This event should be fired from Thunderbird itself after every(!) message, which is be displayed.

jobisoft

Do you have an idea, what could be the reason?

Zitat von Tilo265

while the status bar constantly claims that "plain text" view is active

Is it the statusbar text or the checked entry in the statusbar context menu? It may be a part of the main problem or separate problem (if in the context menu).

Zitat von 5crambler

Now for something completely different, Jorg:

was hat es mit Betterbird auf sich?

Soll man das probieren? Besser als TB? Warum?

Dies besprecht Ihr bitte im passenden Unterforum.

Version 99 Beta bringt ein paar technische Änderungen mit, die von einer größeren Zahl an Anwendern getestet werden sollten:

Topicbox

Zitat von wojtek

Sure thing. And if anything happens - provide log from _after_ using AHT - correct?

If possible the complete log out of error console (including Thunderbirds and the Addons startup).