AttachmentExtractor Continued - Version 4.0 für Thunderbird 91 - aufgegeben

Moin!

Zu Eurer Information:

Es gibt (von einem anderen Autor) eine neue saubere kleine MailExtension, die ganz simpel aus mehreren ausgewählten Nachrichten die Anhänge abtrennen / speichern / löschen kann.

• Den SourceCode dafür findet man schon auf GitHub: https://github.com/thestonehead/T…chmentExtractor
• Den Download dafür wird man auf ATN finden: https://addons.thunderbird.net/de/thunderbird…ment-extractor/

Das genannte neue Add-on ist noch ausbaufähig, was sicherlich Zeit in Anspruch nehmen wird. Ob der Autor dies überhaupt machen wird, bleibt abzuwarten. Ich habe in den letzten Tagen daher doch nochmal ein bisschen an meinem Add-on gearbeitet. Auch hier hilft die von jobisoft weiterentwickelte WindowListener-API, um das "alte" Add-on nochmals mit akzeptablem Aufwand für Thunderbird 78 und vermutlich nun auch 91 lauffähig zu bekommen.

Es wird also in der nächsten Zeit Updates von mir geben:

• Version 3.0 für Thunderbird 78
• Version 4.0 für Thunderbird 91

Ich muss dafür zumindest den Optionen-Dialog (der für ein Add--on durchaus üppig ist) komplett neu in HTML schreiben, da die bisherige Version mit den 6 Seiten so nicht per WL-API funktioniert. Das hat zur Folge, dass ich auch die locales mit der neuen Technik einbinden muss usw...

Danach würde ich dann doch versuchen meinen bisherigen Worten treu zu bleiben und meine Energie (wenn überhaupt) eher in die Übertragung von Features in das Grundgerüst des neuen (fremden) Add-ons zu investieren.

Kleine Rückmeldung zu meiner Bemühung in Richtung Thunderbird 91:

Thunderbird stürzt an einer bestimmten Stelle aewindow.gDBView.loadMessageByViewIndex(vindex); des Add-on-Codes leider komplett ab:

https://gitlab.com/ThunderbirdMai…_window.js#L417

        var msgkey = msg.messageKey;
        var vindex = aewindow.gDBView.findIndexFromKey(msgkey, true);
        aewindow.aedump("[msgkey: " + msgkey + "; view index: " + vindex +
          "; folder: " + (msg.folder ? msg.folder.name : null) + "]\n", 1);
        //aewindow.gDBView.selectMsgByKey(msgkey); //disabled 5/1/07 to fix del/det bug
        aewindow.gDBView.loadMessageByViewIndex(vindex);

Bis einschließlich Thunderbird 78 funktioniert der Code soweit problemlos. Ich habe per https://searchfox.org/ geschaut, ob es Veränderungen bei loadMessageByViewIndex zwischen den Thunderbird-Branches gegeben hat. Leider habe ich aber nichts für mich brauchbares / verständliches gefunden. Warum also stürzt Thunderbird an der Stelle fatal ab?

Im Dump/Log werden die Angaben aus den Zeilen darüber noch korrekt ausgegeben, soweit ich dies erkennen kann. Wenn ich eine Log-Zeile sofort nach der hier genannten fatalen Zeile erstellen lassen will, dann wird diese schon gar nicht mehr im Log ausgegeben. Der Absturz erfolgt also sicher in der genannten Zeile, was ich durch auskommentieren der Zeile auch vermeiden kann. Logischer Weise funktioniert das Add-on ohne die Zeile dann trotzdem nicht mehr

Zitat von Thunder

ob es Veränderungen bei loadMessageByViewIndex zwischen den Thunderbird-Branches gegeben hat

Ich habe weiterhin keine neuen Veränderungen gefunden, was aber nicht heißt, dass es diese nicht gibt. Bei meiner Suche nach vergleichbaren Bugs habe ich folgenden gefunden: https://bugzilla.mozilla.org/show_bug.cgi?id=686123

Thunderbird stürzt auch bei diesem Bug im Kontext von loadMessageByViewIndex ab. Siehe in Beitrag Nummer 9: https://bugzilla.mozilla.org/show_bug.cgi?id=686123#c9. Vielleicht kann jobisoft oder jemand anderes erkennen, was ich im Code des AEC ändern müsste, um das Problem zu verhindern. Wenn ich an der Stelle keine Lösung finde, dann ist der bisherige AEC für Thunderbird 91 "tot" und ich muss dann jetzt "schon" für den 91er ein komplett neues Add-on als MailExtension bauen, welches ich auf Basis des neuen "Konkurenz-Add-ons" aufbauen und erweitern würde. Eigentlich hatte ich aber noch die Hoffnung, dass ich das alte Add-on nochmals für den 91er retten könnte, um dem neuen Add-on mehr Zeit zu geben.

Zitat von jobisoft

Hast du mal geguckt, ob der vindex, den du übergibst, in TB91 evtl Käse ist? Also der eigentliche Fehler irgendwo früher auftritt, wenn du den vindex abholst?

Der vindex stimmt absolut mit dem Wert überein, den man auch in Tb 78 erhält. Wenn ich gerade nicht irre, handelt es sich quasi um die Nummer der Mail (als Integer-Wert, beginnend bei 0) innerhalb des Ordners.

Zitat von Thunder

Wenn ich an der Stelle keine Lösung finde, dann ist der bisherige AEC für Thunderbird 91 "tot" und ich muss dann jetzt "schon" für den 91er ein komplett neues Add-on als MailExtension bauen

Es ist bedauerlich, dass ein einziger (aber fataler) "Fehler" das komplette bisherige Add-on in Thunderbird 91 unbrauchbar macht, da dieser, wie oben beschrieben, kommentarlos abstürzt. Leider gibt es einfach niemanden sonst, der das Problem in seinem "Produkt" ebenfalls hat, weil es schlichtweg keine anderen Add-ons gibt, die die verantwortliche Funktion in Thunderbird aufrufen würden. Ich stehe also alleine mit dem Problem da und habe nun in den letzten 2 Wochen zig Versuche unternommen, um mit dem spärlichen Informationen, die ich mir zusammenreimen konnte, einen Workaround zu schaffen. Leider blieben alle Versuche ohne Erfolg. Die Funktion ist aber so zentral in der Abarbeitung der Tasks im Add-on, dass selbst beim simplen Durchlaufen des Codes (bei entsprechender Einstellung) ohne etwas zu löschen oder zu speichern Thunderbird abstürzt. Damit ist das klassische Add-on wohl tatsächlich für Thunderbird 91 gestorben, wenn nicht ein Wunder geschieht. Es liegt also nicht an der Menge der Arbeit, sondern schlichtweg an einem unvermeidbaren Crash, für den ich überhaupt keinen Grund erkennen kann, da es zwischen Thunderbird 78 und den aktuellen Betas diesbezüglich schlichtweg keine Änderung gab. Und dennoch ist im 78er alles okay, während der 91er crasht.

jobisoft

• Kann man per MailExtension-API in Menüs/Kontextmenüs eigene Untermenüs kreieren? Oder kann ich bisher nur einen einfach Menüpunkt einfügen?
• Dropdowns an einem Toolbar-Button funktionieren ja scheinbar auch noch nicht (aktuelle Diskussion auf Topicbox)?
• Siehst Du einen Weg, wie ich über mehrere Ordner hinweg alle Attachments aller Nachrichten speichern bzw. löschen lasse, wenn ich den Code des anderen/neuen Konkurrenz-Addons anpasse?
• Sehe ich es richtig, dass in dem anderen Add-on "auf einen Schlag" alle Mails und Attachments in einem Array gesammelt werden, um diese abzuarbeiten. Warnt der Autor deshalb im Readme vor Arbeitsspeicher-Problemen, wenn man zu viele auf einmal auswählt? Meine naive Idee dazu wäre, dass ich beim Löschen über mehrere Ordner hinweg in der Schleife über die Ordner per await bzw. .then() einen Ordner nach dem Anderen abarbeiten lassen würde. Wäre dies möglich? Leider verstehe ich alles rund um async ja immer noch nicht richtig

Zitat von jobisoft

Sobald du mehr als ein Menu hinzufügst, werden die in einem Untermenu (mit deinem Extensionnamen) gesammelt.

Okay, immerhin. Dann muss man das Attachment so benennen, wie der Menüeintrag für das Submenü heißen soll .

Zitat von jobisoft

Prinzipiell hat das Memory Problem aber nix mit async/await zu tun.

Das war mir klar. Wobei ich mir vorstellen kann, dass async zu parallelen Prozessen führt, was dann doch mehr Speicherplatz verbrauchen könnte.

Zitat von jobisoft

sondern jede message vollständig bearbeiten und dann zu nächsten loopen.

Was ein Unterschied zu dem anderen Add-on wäre, wenn ich es im Code dort richtig verstehe.

Zitat von jobisoft

Ich denke du solltest nicht alle Attachments sammeln und dann abarbeiten, sondern jede message vollständig bearbeiten und dann zu nächsten loopen.

So wäre eigentlich eh meine Vorstellung. Ich muss mir nochmal genau anschauen, welche bisherigen Detach-Funktionen 1.) ohne erzwungene Dialoge für die Massenverarbeitung geeignet sind und 2.) den Speicherpfad der abgetrennten Dateien in der Mail drin behalten. Vielleicht bekomme ich dies dann doch hin, wenn man einen neuen/anderen Ansatz gegenüber dem alten AEC verfolgt. Aus dem Bauch und der Erinnerung heraus habe ich allerdings Zweifel.

Zitat von jobisoft

Du bist herzlich zu unseren developer zoom meetings eingeladen, da sind die Promises auch immer wieder Thema.

Eigentlich würde ich da gerne teilnehmen, allerdings sehe ich da Probleme im häuslichen Hintergrund .

Zitat von jobisoft

Steht aber recht weit oben auf meiner Liste

Es wäre ein Traum, wenn dabei gleich noch mein Wunsch "Provide an additional save path attribute in function call nsMessenger::DetachAllAttachments()." erfüllt würde, den zumindest JorgK durchaus nachvollziehen konnte:

Zitat

Yes, it's unfortunate that the code in mailnews/base/src/nsMessenger.cpp does some mandatory prompting in the backend.

I'm sure we'd accept a patch for this.

Statusbericht auf dem Weg zur MailExtension:

Grundlegend funktioniert dies jetzt schon:

Buttons:

• in der Main-Toolbar
• in der Header-Toolbar

Kontextmenü mit Untermenü:

• in der Nachrichten-/Themenliste

Aktivieren / Deaktivieren der Bedienelemente, abhängig vom angezeigten Kontext

Manuelles Ausführen:

• Speichern von Dateianhängen
• Abtrennen (also löschen nach dem Speichern) von Dateianhängen (leider weiterhin ohne Link zur Datei auf Festplatte)

Automatik:

• Erkennen neuer Nachrichten und Ausführen der bisher vorhandenen Funktionen (siehe bei manuell) - leider "feuert" der notwendige event noch zu oft zu unrecht (siehe Bug 1716051)
• Berücksichtigen, ob ein bestimmtes Schlagwort notwendig ist, um die Nachricht zu verarbeiten

Es ist noch ein weiter Weg bis zum fertigen Add-on:

• i18n
• Prefs + kompletter neuer Optionen-Dialog
• und vieles mehr

Zitat von Thunder

Es ist noch ein weiter Weg bis zum fertigen Add-on:

i18n
Prefs + kompletter neuer Optionen-Dialog
und vieles mehr

Übersetzung + Optionen inkl. Dialog habe ich in der Zwischenzeit soweit eingebaut. Die Entwicklung ist dennoch ins Stocken geraten, da ich auf gleich mehrere Probleme innerhalb von Thunderbird (ausbleibende oder falsche "events") gestoßen bin, wodurch die Automatik vielfältig versagen kann. An der Lösung dieser event-Probleme wird aber von jobisoft gearbeitet . Es bleibt dann noch ein Versagen im Zusammenhang mit Filtern, weshalb man die Reihenfolge von Aktionen in Filtern berücksichtigen muss, wenn man für die AEC-Automatik mit Tags arbeitet.

Ich habe die Tage schon mal kurz getestet, hatte aber keine konzentrierte Ruhe dabei, sodass ich dies heute nochmal in Ruhe anschauen möchte. Sorry, dass ich dazu bisher nicht kommentiert hatte.

Was auf jeden Fall als Problem bestehen geblieben ist, ist der API-unabhängige Bug, dass der Filter die "Tag"-Aktion nach verschieben der Mail nicht ausführt. Dazu muss ich wohl mal einen Bug aufmachen.

Zitat von Thunder

Dazu muss ich wohl mal einen Bug aufmachen.

Zitat von jobisoft

Hast du meine Kommentare im Bug gesehen? Inzwischen wurde der bug als gefixed geschlossen.
https://bugzilla.mozilla.org/show_bug.cgi?id=1716051#c10

Sollte im aktuellen Daily drin sein, inzwischen.

Leider hat entweder dieser Patch oder etwas anderes eine Regression erzeugt: Der event onNewMailReceived müsste ja die beiden Objekte folder, messages zurück geben. folder ist jetzt aber immer null. Dieses Problem habe ich in Deinem speziellen Build genauso wie in den aktuellen Daily-Builds. In 91 Beta 2 ist dies aber noch in Ordnung.

Zitat von jobisoft

danke fürs finden, ich geh das mal fixen.

Super, wenn Du's so schnell nachvollziehen kannst - Danke!

jobisoft

Thunderbird Daily vom 23.7. hat jetzt Deinen letzten Patch für den event mit drin. Damit habe ich die letzte halbe Stunde Tests durchgeführt. Das folder Object wird wieder korrekt zurückgegeben.

Ich schreibe dies hier auf Deutsch, da ich mich einfach besser ausdrücken kann...

STR:

1. Um den Fehler nachvollziehen zu können ist es notwendig, um Dein simples Event-Addon und meine momentane Entwickler-Version von AEC installiert zu haben.
2. In meinem Add-on muss die Abtrenn-Automatik aktiviert sein - nur bei dieser Aktion ist das Verhalten zu provozieren bzw. zu erkennen.
3. Sende Dir eine Nachricht mit Attachment (am besten von außerhalb des Entwickler-Thunderbirds!).
4. Sorge dafür, dass im empfangenden Thunderbird der Fokus auf einem anderen Ordner ist (also nicht auf dem Posteingang).
5. Die Automatik von AEC erkennt die neue Mail inkl. Anhang und bringt den kleinen Dialog für das Dateinamen-Muster. Befolge bitte die 3 Dialoge (Dateinamen-Muster, Speicherort und Frage, ob wirklich der Anhang gelöscht werden soll - JA, der Anhang soll gelöscht werden!).
6. Es wird von der Detach-Funktion aus technischer Sicht eine Kopie der Mail mit Verweis auf den gelöschten Anhang erstellt. Eigentlich müsste die originale Mail in diesem Moment gelöscht werden. Außerdem dürfte jetzt nicht erneut der event onNewMailReceived gefeuert werden.

Und genau in Punkt 6 liegt nun gleich der doppelte Fehler:

• Die originale Mail wird nicht gelöscht
• Der event wird (wohl als Folgeerscheinung) zu Unrecht erneut gefeuert

Wenn man obige Schritte macht, während der Fokus im Posteingang (bzw. im Ordner mit der originalen empfangenen Mail mit Anhang ist), dann werden die Schritte von Thunderbird korrekt erledigt.

Zitat von jobisoft

Die originale Mail wird nicht gelöscht:

* Ist das neu? Siehst du einen Zusammenhang mit meinen letzten API Änderungen?

Nein. Das Phänomen gibt es schon lange. Ich bin dem nur nie systematisch nachgegangen.

Zitat von jobisoft

Der event wird (wohl als Folgeerscheinung) zu Unrecht erneut gefeuert:

* Ist das neu? Hat meine "alte" Version des onNewMailReceived events mit der manuellen "kenn ich schon" Unterdrückung da nicht gefeuert?
* Feuert TB selber?

Es ist vermutlich nicht neu. Und JA, Thunderbird feuert auch selbst - es gibt ja auch eine zweite Mail, da die Originale nicht gelöscht wird.

Zitat von jobisoft

Das detach ist legacy code von dir?

Ja, aber es handelt sich dabei ja um eine Thunderbird eigene Funktion:

messenger.detachAllAttachments(
                  types[i],
                  attachmentUrls[i],
                  originalFilenames[i],
                  messageUrls[i],
                  false,
                  true
                );

Das folgende Addon ist ausdrücklich NUR für Versuche geeignet! Normale Anwender sollen dieses Add-on nicht installieren und verwenden!

attachment-extractor-continued_20210723-160626.xpi