AttachmentExtractor Continued - Version 4.0 für Thunderbird 91

  • 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.

    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/Thunderbird…ent/aec_js_window.js#L417


    JavaScript
            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 ;-)

  • 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.

  • Core benutzt die JavaScript Schnittstelle nicht, da ist es schwer zu sehen, ob sich was geändert hat. Alle core consumer sind c++. Und es taucht in ThunderKDB [1] auch kein anderes add-on auf, dass das macht.


    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?


    [1] https://github.com/search?q=lo…ext-experiments&type=Code

  • 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.

  • 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 ;-)
  • 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?

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



    Dropdowns an einem Toolbar-Button funktionieren ja scheinbar auch noch nicht (aktuelle Diskussion auf Topicbox)?

    Korrekt, die Tests wollen nicht. Ich überlege aber die Dropdowns auch zu anderen Buttons hinzuzufügen, und dann wäre dieser Teil unabhängig von den action buttons. Das ist aber noch nicht ausgegohren. Backward incompatible will ich aber auch nicht werden, daher erstmal auf Eis.



    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?

    Nur indem du über alle ordner und nachrichten loopst, ist aber nicht schwer. Über die accounts API bekommst du von jedem account den root folder, und über die kannst du rekursiv loopen und über messages.list() bekommst du alle messages und kannst die dann in einem Experiment detachen - solange wir noch keine API dafür haben.


    Steht aber recht weit oben auf meiner Liste, zusammen mit Message move/copy


    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


    Du bist herzlich zu unseren developer zoom meetings eingeladen, da sind die Promises auch immer wieder Thema. Prinzipiell hat das Memory Problem aber nix mit async/await zu tun. Ich denke du solltest nicht alle Attachments sammeln und dann abarbeiten, sondern jede message vollständig bearbeiten und dann zu nächsten loopen.

  • 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 :P .

    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.


    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.


    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.


    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 :whistling: .

  • 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:

    Quote

    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