Beiträge von Thunder

Die relevanten Prefs zu .detachMode:

actionafterextract.detach.mode

autoextract.detach.mode

und zu isExtractEnabled:

extract.mode

Übrigens wird der Begriff bzw. die Variablen "...detach" eigentlich verwirrend verwendet. Detach kann mit oder ohne Löschen sein... Und Detach kann auch ohne Speichern sein, so dass nur gelöscht wird oder dass die Attachments gar nicht angefasst werden, sondern nur die Mail selbst manipuliert wird. Im JS-Code sind zwei Variablen entscheidend/hilfreich für mich:

.detachMode (aus den allgemeinen Einstellungen)

• kann 0, 1 oder 2 sein (im manuellen Modus)
  kann 1 oder 2 sein (im Automatik-Modus)
  0 = Löschen mit Thunderbirds Routinen
  1 = Löschen mit AE-Routinen
  2 = nur Abtrennen mit AE-Routinen
• Ich habe diese Option quasi inaktiviert, indem ich sie an 2 initialen Stellen einfach mit "0" überschreibe. Somit wird immer mit Thunderbirds eigenen Routinen gelöscht. Zusätzlich habe ich dazu eine neue Option eingeführt, die festlegt ob für das Löschen jeweils pro E-Mail eine Rückfrage erfolgen soll: .detachWithoutConfirmation
  Das funktioniert bei meinem Tests absolut einwandfrei.

Es wäre denkbar, dass meine obigen Maßnahmen momentan zu Folge-Fehlern in der Logik der Funktionen führen, wenn es nun um folgendes geht:

isExtractEnabled (aus den erweiterten Einstellungen)

In den erweiterten Einstellungen kann man das Speichern der Attachments ganz deaktivieren oder zwischen Thunderbird- und AE-Abtrennfunktion wählen. Diese Option überschneidet sich mit der vorherigen Option, die ich ja letztlich zur Zeit ausgeblendet und überschrieben habe.

Zitat von jobisoft

der Unterschied zwischen aeMessenger.saveAttachmentToFolder und aewindow.messenger.saveAttachmentToFile

aeMessenger.saveAttachmentToFolder ist die "eigene" Routine des Attachments, die scheinbar aus dem C++ abgeleitet wurde. Dies wird momentan wohl nur noch gebraucht, wenn man bestimmte Attachments aus dem Objekt/Array raus nehmen möchte (aufgrund der Dateigröße), oder wenn man das Datum der zu speichernden Attachments mit dem Empfangsdatum der jeweiligen E-Mail machen will (also letztlich das Datum in den Meta-Daten der resultierenden Datei auf der Festplatte).

aewindow.messenger.saveAttachmentToFile ist der Aufruf von Thunderbirds eigener Detach-Routine. Ich konnte für diese Routine bereits erreichen, dass (optional) nicht mehr bei jeder E-Mail gefragt wird, ob die Dateien tatsächlich gelöscht werden sollen.

Zitat von jobisoft

aeMessenger.saveAttachmentToFolder ist die Funktion, die am Ende die problematische startupUrl Funktion aufruft, richtig?

Das ist richtig.

Zitat von jobisoft

Trennen beide Funktionen auch das Attachment ab (also löschen es aus der Mail?) . Wo passiert das?

        case states.DETACH:
          if (thistask.isDetachEnabled && !this.isNewsMessage() && !this
            .isRSSMessage()) {
            aewindow.aedump('{function:AEMessage.doDetach}\n', 2);
            aewindow.progress_tracker.state = states.DETACH;
            thistask.listeningforMessageId = thistask.getMessageHeader()
              .messageId;
            var acl = aewindow.arraycompact(this.attachments_ct);
            if (acl.length > 0) {
              if (thistask.detachMode !== 0) {
                // AEC experimental detach routines
                aewindow.aedump('>>>> thistask.detachMode !== 0 \n', 2);
                var deleteAtt = (thistask.detachMode === 1) || !thistask
                  .isExtractEnabled;
                var savedfiles = (deleteAtt) ? null : aewindow
                  .arraycompact(this.attachments_savedfile);
                this.detachTempFile = aeMessenger.detachAttachments(
                  aewindow.messenger, aewindow.msgWindow, acl,
                  aewindow.arraycompact(this.attachments_url),
                  // use .map(encodeURIComponent) to display nonASCII correct
                  // if there is an confirmation dialog
                  aewindow.arraycompact(this.attachments_display.map(encodeURIComponent)),
                  aewindow.arraycompact(this.attachments_uri),
                  savedfiles);
                } else {
                // Thunderbirds own detach routines
                aewindow.aedump('>>>> thistask.detachMode === 0 \n', 2);
                aewindow.messenger.detachAllAttachments(acl.length, acl,
                  aewindow.arraycompact(this.attachments_url),
                  // use .map(encodeURIComponent) to display nonASCII correct
                  // if there is an confirmation dialog
                  aewindow.arraycompact(this.attachments_display.map(encodeURIComponent)),
                  aewindow.arraycompact(this.attachments_uri),
                  false,  // false = do not save(?) or ask for destination folder (?)
                  thistask.detachWithoutConfirmation  // if true = delete without warning
                ); 
              }
              // console.log("setTimeout");
              // seems to be working okay
              thistask.detachCancellationTimeout = setTimeout(function() {
                aewindow.currentMessage.doAfterActions(states
                .DELTEMPFILE)
              }, 2000);
              break;
            }
          }

Die "eigenen" Routinen des Add-ons verstehe ich leider oftmals auch noch nicht richtig. In obigem Code habe ich comments drin, wo ae-eigener Code und wo Thunderbirds Code beginnt bzw. aufgerufen wird.

Zitat von jobisoft

Wenn du mit TB68 testen willst, es gibt jetzt release candidates:

https://ftp.mozilla.org/pub/thunderbir…8.0-candidates/

Danke, ich verfolge die Newgroup in der das geschrieben wurde und habe dort auch Deine Beiträge gesehen

Momentan teste ich primär mit dem 68er RC, aber auch mit der 69er-Beta. Das erspart mir hoffentlich, dass ich Dinge "programmiere", die anschließend nicht mehr zu gebrauchen sind. Dabei ist mir auch schon aufgefallen, dass ab dem 69er dann die Toolbar-Menu-Buttons folgendes im XUL benötigen: is="toolbar-menu-button", was aber auch im 68er schon drin stehen darf ohne Probleme zu machen.

Zitat von jobisoft

fur XUL elemente document.createXULElement benutzen.

Offensichtlich geht das auch schon (ab circa Version 64) für Thunderbird 68?

The requested feature is existing. Have a look in the advanced options - there you can enable the feature.

I am currently updating the add-on for the upcoming Thunderbird 68. The work on this is going very well, so I hope to be able to release this Update short after Thunderbird 68.

Ein paar weitere Anmerkungen/Fragen:

1.) Das bisherige Hauptproblem mit der defekten "createStartupUrl"-Funktion und deren Folgen könnte man igonieren (und den zugehörigen wohl aus C++ portierten JS-Code löschen), wenn ich zumindest die Abfrage der Attachmentgrößen auch in die Standard-Routinen integrieren könnte, mit denen eigentlich alles andere im Add-on gemacht wird.

2.) Ich bräuchte leider auch gleich ein bisschen Information zu document.createElement ab Thunderbird 69 Beta. Ansonsten brauche ich erst gar nicht anzufangen, die menuitem für die neu integrierten Favoritenordner zu programmieren. An den ab 69 Beta defekten "Zuletzt verwendeten Ordnern" sehe ich schon, dass da auch wieder Arbeit auf mich zukommt.

In der Zwischenzeit habe ich einen neuen Snapshot-Tag in GitLab erstellt, auf dessen Basis wir weiter machen können:

https://gitlab.com/ThunderbirdMai…/2.0a1-20190810

In diesem Snapshot funktioniert nun fast alles. Aber die Funktion "createStartupUrl" versagt weiterhin. Daher funktioniert das Add-on noch nicht, wenn man in dessen Einstellungen → Erweitert → "Anhänge mit interner Routine ... abtrennen" auswählt. Dies wäre notwendig, wenn man für die abzutrennenden Anhänge das Eingangsdatum der Mail nutzen will und/oder die Dateigröße der Anhänge für das Abtrennen berücksichtigt werden soll.

Die alte, originale Funktion (auskommentiert):

https://gitlab.com/ThunderbirdMai…ssenger.js#L539

Die momentane (ebenfalls nicht funktionierende) Funktion:

https://gitlab.com/ThunderbirdMai…ssenger.js#L566

Genutzt wird die Funktion eigentlich nur einmal im kompletten Add-on von dieser Stelle aus:

https://gitlab.com/ThunderbirdMai…ssenger.js#L433

Danke für weitere Hilfe und Ideen von Dir/Euch!

Da meine eigenen Add-ons für Thunderbird 68 fertig / lauffähig sind, schließe ich dieses übergreifende Thema jetzt.

Alles Weitere zum AttachmentExtractor schreibe ich direkt in dem passenden Unter-Forum.

Zitat von jobisoft

Ok, wenn das Ding wirklich nur ein String ist, dann mach die URL Manipulation mal als reine String-Manipulation und ersetzte Zeile 453-456 durch:

messageUri = messageUri + "?header=saveas";

Was passiert?

Dann kommt folgende Fehlermeldung (wobei die Zeilennummer 764 evtl. nicht zum bisherigen Code passt, da ich alle möglichen Zeilen/Versuche momentan im Code drin habe:

Zitat

Could not convert JavaScript argument - 0 was passed, expected object. Did you mean null? arg 0 [nsIScriptableInputStream.init]" nsresult: "0x80570035 (NS_ERROR_XPC_BAD_CONVERT_JS_ZERO_ISNOT_NULL)" location: "JS frame :: chrome://attachmentextractor_cont/content/aec_js_messenger.js :: aeSaveMsgListener/this.onDataAvailable :: line 764"

Zitat von jobisoft

createStartupUrl: function(url) {
return Services.io.newURI(url);
}

geht nicht - bringt weitere Fehler

Momentan habe ich entdeckt, dass ich zumindest für das Unterlassen der Rückfrage, ob Attachments gelöscht werden sollen, doch auch Thunderbirds eigene Routinen verwenden kann. Das hilft schon mal an wichtiger Stelle weiter. Außerdem konnte ich scheinbar das verdammte "eval()" an anderer Code-Stelle tatsächlich erfolgreich ersetzen.

In den nächsten Tagen erstelle ich nochmal einen Snapshot bzw. ein aktuelles Tag in GitLab, auf das man sich dann mit den Zeilennummern wieder korrekt beziehen kann und melde mich dann wieder.

Zitat von jobisoft

Bist du Dir sicher, dass messageUri wirklich eine Uri ist?

Ich vermute, der ursprüngliche Autor hat "URL" als Teilmenge von "URI" angenommen. Somit wäre jede URL letztlich auch eine URI, obwohl die URL ja mehr Information (Protokoll und Pfad) bietet als eine einfache URI.

Zitat von jobisoft

das gibt einen String zurück, oder? Kannst du das mal dumpen?

https://searchfox.org/comm-central/s…gFolder.idl#409

Das liefert beispielsweise folgendes:

mailbox-message://nobody@Local%20Folders/Test-Ordner#19

Zitat von jobisoft

Was passiert denn, wenn du Zeile 453-456 einfach auskommentierst?

Im Falle des zu speichernden Nachrichtentexts (also Zeile 453-456) wird dann eine leere Datei ohne den Nachrichtentext erstellt. Wenn ich das mutate() weiter unten (Zeile 455) auskommentiere, wird bemängelt, dass die Datei (das Attachment) nicht gefunden werden konnte und es wird somit auch nicht gespeichert.

Allerdings muss man sagen, dass das mutate() so wie von mir verwendet sowieso überhaupt nicht funktioniert hat.

Nein, das mit der Uri funktioniert so nicht. Kann es meines Erachtens auch nicht, da ich (meinem Verständnis nach) ja einer Art object eine property (die ".spec") zuweise bzw. diese überschreiben möchte. Deine Variante hätte das komplette object überschrieben. Da ich leider nur Learning-by-Doing-Ahnung habe, kann ich mich nicht korrekt ausdrücken, was es Dir vermutlich leichter machen würde .

Bezüglich CID:

https://gitlab.com/ThunderbirdMai…ssenger.js#L537

Bezüglich Mutator:

Hier: https://gitlab.com/ThunderbirdMai…ssenger.js#L455

Und hier: https://gitlab.com/ThunderbirdMai…ssenger.js#L555

Vielleicht hilft Dir wegen des Mutators auch die Info von Jörg etwas weiter:

http://lists.thunderbird.net/pipermail/mail…rch/001050.html

Vielen Dank

Das Problem mit der CID ist, dass es die alte CID scheinbar nicht mehr gibt. Ich muss aber irgendwie auf die (vermutliche) neue "Komponente" zugreifen, die nun aber keine klassische CID anbietet, sondern so aussieht:

#define NS_IMAPURL_CID        \
{ 0x21a89611, 0xdc0d, 0x11d2, \
{ 0x80, 0x6c, 0x0, 0x60, 0x8, 0x12, 0x8c, 0x4e }}

Zuletzt dann noch die Optionen "Erweitert":

Wenn Ihr Euch die 4 Seiten der Optionen anschaut, könnt Ihr erkennen, dass ich gegenüber dem ursprünglichen Add-on ein wenig umsortiert habe, um die Logik zu verbessern.

Die Option "Korrektur anwenden, um abgetrennte Grafiken eingebettet anzuzeigen" werde ich vermutlich entfernen. Diese Funktion ist momentan sowieso defekt und schon der Ursprungsautor hat darin Sicherheitsbedenken angegeben.

Die Optionen für die "Dateinamen" (also das Dateinamenmuster) der gespeicherten Attachments:

Hier die Optionen der "Abtrennautomatik", die bei neu empfangenen E-Mails automatisch arbeitet:

Für die Zwischenzeit habe ich mal einen Preview des neuen Optionen-Dialogs (an den man sich grundlegend in Thunderbird ab Version 68 gewöhnen muss). Die Haken, Fragezeichen und Kreuze zeigen Euch, was bisher schon korrekt funktioniert.

Die Einstellungen "Allgemein" stehen für den manuellen Modus, bei dem man bestimmte E-Mails oder Ordner auswählt, um deren Anhänge zu bearbeiten, und dann per Schaltfläche oder (Kontext-)Menü die Aktion startet. Was hier im manuellen Modus funktioniert oder eben auch noch nicht, das gilt identisch für die Abtrennautomatik, falls man diese benutzt. Die Automatik hat ein paar Optionen weniger, da diese dort keinen Sinn machen würden.

Hast Du in Thunderbird eigentlich mal zusätzlich zu "Datum" die Spalte "Empfangen" aktiviert? Vielleicht wird da die Reihenfolge korrekt dargestellt, wenn die Mails in korrekter Reihenfolge auf dem IMAP bzw. in Thunderbird eingehen.

Wenn ich mir den Ablauf anschaue, dann ist das erste/obere Beispiel per Freenet-SMTP versendet worden, oder? Vom identischen Gerät? Dann dürfte der Freenet-SMTP (von denen selbst) falsch konfiguriert sein.

Ich brauche mal Eure Hilfe, um ein paar Schritte voran zu kommen:

1.) {21A89611-DC0D-11d2-806C-006008128C4E} gibt es nicht mehr

In früheren Thunderbird-Versionen gab es in mailnews/imap/public/nsMsgImapCID.h die CID {21A89611-DC0D-11d2-806C-006008128C4E}. Dabei handelt es sich vermutlich um die NSIMAP URL Klasse (schlagt mich nicht, wenn ich den Begriff unpassend gewählt habe). Per Components.classesByID konnte man diese in JavaScript einbinden.

Diese CID gibt es inzwischen nicht mehr. In der aktuellen Datei comm-central/comm/mailnews/imap/public/nsMsgImapCID.h dürfte es sich nun um folgenden Service handeln:

#define NS_IMAPURL_CID        \
{ 0x21a89611, 0xdc0d, 0x11d2, \
{ 0x80, 0x6c, 0x0, 0x60, 0x8, 0x12, 0x8c, 0x4e }}

Wie kann ich das nun wieder in JavaScript einbinden bzw. hat jemand einen anderen Vorschlag, wie ich die alte Variante ersetzen kann?

2.) nsIURI.spec is read-only, use url.mutate().setSpec(aSpec).finalize();

Dies habe ich versucht umzusetzen, scheitere aber offensichtlich, da das JS an der Stelle abstürzt, soweit ich dies erkennen kann.

Da url.spec weiterhin lesend vorhanden ist, habe ich es entsprechend nur an 2 Stellen im Code geändert, wo schreibend darauf zugegriffen werden soll.

Folgendes wird für die internen Routinen zum Abtrennen der Attachments verwendet - der Fehler tritt also auch nur bei entsprechender Einstellung des Add-ons auf:

// Die nächste Zeile scheitert aktuell noch an der geänderten CID (siehe oben)
obj = Components.classesByID["{21a89611-dc0d-11d2-806c-006008128c4e}"];

var startupUrl = obj.createInstance(Ci.nsIURI);

// nsIURI.spec is read-only, use url.mutate().setSpec(aSpec).finalize();
// Die alte Zeile sieht so aus:
// startupUrl.spec = uri;

// braucht man überhaupt Ci.nsIURIMutator ? Ist das mit den Components.interfaces automatisch eingebunden?
if (Ci.nsIURIMutator) {
  startupUrl = startupUrl.mutate().setSpec(uri).finalize();
}
// wie muss das Konstrukt korrekt aussehen, um weiter zu kommen?

Die zweite Stelle im Code wird für das Speichern des Nachrichtentexts in separaten HTML-Dateien verwendet, wenn im Add-on aktiviert:

var messageUri = message.folder.getUriForMsg(message);
var msgService = aewindow.messenger.messageServiceFromURI(messageUri);
var saveListener = new aeSaveMsgListener(
        file, 
        aewindow.messenger, 
        "",
        "aewindow.currentTask.currentMessage.doAfterActions(aewindow.progress_tracker.message_states.CLEARTAG)",
        aewindow, 
        0);

// nsIURI.spec is read-only, use url.mutate().setSpec(aSpec).finalize();
// Die alte Zeile sieht so aus:
// messageUri.spec = messageUri.spec + "?header=saveas";

if (Ci.nsIURIMutator) {
  messageUri = messageUri.mutate().setSpec(messageUri.spec + "?header=saveas").finalize();
}
// wie muss das Konstrukt korrekt aussehen, um weiter zu kommen?

Der Code stammt (ohne obige erweiterte Kommentare) aus folgendem Entwicklungsstand des AEC aus der Datei aec_js_messenger.js (Suche im Code am besten per nsIURI.spec is read-only, use url.mutate().setSpec(aSpec).finalize();

https://gitlab.com/ThunderbirdMai…/2.0a1-20190801

Wenn ich diese beiden Dinge endlich funktionierend habe, kann ich weiter schauen und komme bestimmt wieder mit Fragen.

jobisoft  Paenglab Vielleicht könnt Ihr mir hier unter die Arme greifen?

Danke Euch für jegliche Hilfe