AttachmentExtractor wird zu "AttachmentExtractor Continued" für Thunderbird 60 und 68
-
Thunder -
26. Dezember 2018 um 02:00 -
Geschlossen -
Unerledigt
-
-
-
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.
-
-
Du erstellst einfach ein komplett neues nsIUri object. Der constructor nimmt dazu eine komplette url, die du wie du es brauchst zusammenbauen kannst. Wenn die url nicht gültig ist, wirft der einen Fehler. Also am besten in einen try ... catch Block Und den Fehlet irgendwie behandeln/abfangen.
Was ist das CID Problem? Das hab ich nicht verstanden.
-
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:
-
Hat das mit der Uri funktioniert?
Kannst du die codestelle verlinken, wo der alte Code auf das CID Gedöns zugreift? Würde gern wissen, was er dann damit macht. Brauche etwas context...
Vg
John
-
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
-
Uri: doch, genau so sollte das gehen. Ich mache es so. Guck dir mal die Definition von nsIUri an. Das ist einfach nur ein Object um eine URL herum mit convinient Methoden wie .spec oder .host oder .schema um auf Teile der URL zuzugreifen, ohne selber den URL String parsen zu müssen. Wenn du die URL des Objekts ändern willst, dann mach einfach ein neues. Wirklich.
Den anderen Kram guck ich mir heute Abebd an. In einer Woche kann ich auch code beisteuern.
-
Bist du Dir sicher, dass messageUri wirklich eine Uri ist?
https://gitlab.com/ThunderbirdMai…ssenger.js#L446
das gibt einen String zurück, oder? Kannst du das mal dumpen?
https://searchfox.org/comm-central/s…gFolder.idl#409
Das erklärt auch:
https://gitlab.com/ThunderbirdMai…ssenger.js#L463
wo ebenfalls ein String erwartet wird.
Was passiert denn, wenn du Zeile 453-456 einfach auskommentierst?
-
Diese CID gibt es inzwischen nicht mehr.
Nur kurz dazu: es sieht mir danach aus, als gäbe das die CID durchaus noch. Zumindest in meinem Build wurde aber Components.classesByID entfernt. Wenn ich das gerade richtig sehe ist das Absicht, und es gibt keinen Weg mehr eine Klasse mit JS über die ID zu bekommen.
These two interfaces are effectively never used, so to avoid needing to support ClassID2JSValue with the new implementation, I remove them entirely.
Wenn es zwingend nsImapUrl sein muss und es eine andere Implementation von nsIUrl nicht tut, musst Du also vermutlich nativen Code finden, der sich als Konstruktor (miss)brauchen lässt. Wenn es den nicht gibt, bitte die Thunderbird-Entwickler um eine ContractID für die Klasse, dann kannst du sie über Components.classes bekommen. Ob man das aber noch in Thunderbird 68 unterkriegt kann ich nicht abschätzen...
Viel Erfolg!
-
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.
das gibt einen String zurück, oder? Kannst du das mal dumpen?
Das liefert beispielsweise folgendes:
mailbox-message://nobody@Local%20Folders/Test-Ordner#19
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.
-
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?
-
Bzgl CID, bei der Definition von newURI steht:
https://searchfox.org/comm-central/s…OService.idl#31
Das Ding wählt also selber das richtige Protokoll anhand der URL aus. Evtl brauchst du das ganze if else Geraffel nicht und createStartupUrl könnte komplett ersetzt werden durch:
Was passiert?
-
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:
ZitatCould 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"
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.
-
Schade, dass das nicht geklappt hat. Ja, sag Bescheid, wenn der Code aktualisiert wurde. Nächste Woche bin ich wieder zu Hause, dann kann ich meine Vorschläge direkt auch selber ausprobieren
-
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!
-
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.
-
Ganz kurz: ab 69 musst du fur XUL elemente document.createXULElement benutzen.
Leider stecke ich gerade selber fest, melde mich später.
-
fur XUL elemente document.createXULElement benutzen.
Offensichtlich geht das auch schon (ab circa Version 64) für Thunderbird 68?
-