Pdf.js: Speicherleck: Einige Ereignisse sind nicht unregistriert

Danke, ich glaube du hast recht. Ich denke nicht, dass es unbedingt ein Speicherleck ist, aber dies sollte ein wenig umgestaltet werden, damit das Binden / Aufheben der Bindung von Fensterereignissen nur an einer Stelle erfolgt.

Scheint nicht so einfach zu sein, obwohl ich noch nicht weiß warum:

• Der Keydown-Listener wird beim Laden des Skripts viewer.js registriert, egal ob ein PDF vorliegt oder nicht.
• Ich habe den removeEventListener wie vorgeschlagen hinzugefügt. Zu meiner Überraschung macht CMD+P nichts (außer das "Bearbeiten"-Menü für den Bruchteil einer Sekunde hervorzuheben). Vielleicht ist das ein OSX-Problem. Meine Theorie ist, dass die Registrierung des "keydown" -Ereignisses automatisch die Standardtastenbelegung beendet. Wenn das stimmt, könnten wir es einfach erneut an window.print() binden.

Übrigens, hier sind meine Quellcode-Änderungen: https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

Vergiss meinen letzten Beitrag - ich habe es geschafft, alles zum Laufen zu bringen. Es ist möglich, die Standardfunktionalität wiederherzustellen, nachdem pdf.js aus dem DOM entfernt wurde. Siehe auch #10948, eine unerwartete Nebenwirkung, die mich gestern verwirrt hat.

Im Pull-Request #11380 werden nun auch zwei der drei registrierten Event-Listener beim Zurücksetzen abgemeldet. Für dieses Problem bleibt nur der Ereignis-Listener print keydown übrig.

Im Pull-Request #11380 werden nun auch zwei der drei registrierten Event-Listener beim Zurücksetzen abgemeldet.

Ja, aber diese Ereignisse wurden nur indirekt behoben, da es aus anderen Gründen (z. B. Konsistenz mit anderen Komponenten) sinnvoll war, das Zurücksetzen einer PDFHistory Instanz zu ermöglichen.

Im Allgemeinen wäre ich jedoch sehr versucht, WONTFIX für den PDFPrintService Code vorzuschlagen, und zwar aus mehreren Gründen:

• Dieses Problem behauptet, dass es Speicherlecks gibt, liefert jedoch keine Beweise dafür.
• Die einzige Einbettung, die der Standard-Viewer wirklich unterstützt, ist eine <iframe> , wobei ich mir nicht vorstellen kann, dass diese Ereignis-Listener irgendwelche Probleme verursachen sollten.[1]
• Dies wirkt sich überhaupt nicht auf das FirefoxPrintService , da es keine Ereignisse registriert. Daher würde der Versuch, dies in den PDFPrintService zu "korrigieren", die verschiedenen PDFPrintServiceFactory Schnittstellen "unausgeglichen" machen.
• Es gibt eine Reihe von window Ereignissen, die in web/pdf_print_service.js registriert werden, und ich denke, dass Sie sie sofort nach dem Laden registrieren müssen, um keine Ereignisse zu verpassen und/oder nicht der erste Ereignishandler zu sein. Folglich kann zu unerwartetem Verhalten führen später damit diese Ereignis - Listener zu entfernen.

[1] Beachten Sie auch http://mozilla.github.io/pdf.js/getting_started/#introduction (Hervorhebung von mir):

Der Viewer basiert auf der Anzeigeebene und ist die Benutzeroberfläche für den PDF-Viewer in Firefox und den anderen Browsererweiterungen innerhalb des Projekts. Es kann ein guter Ausgangspunkt sein, um einen eigenen Viewer zu erstellen. Wenn Sie jedoch planen, den Viewer in Ihre eigene Site einzubetten, bitten wir Sie, dass es sich nicht nur um eine unveränderte Version handelt.

@Snuffleupagus Ich kann mich dem Eindruck nicht entziehen, dass Sie das Projekt ngx-extended-pdf-viewer missbilligen. Ist das richtig? Wenn ja warum?

Nur fürs Protokoll: ngx-extended-pdf-viewer baut auf pdf.js auf. Es fügt 62 Modifikationen zu den Kerndateien pdf.js hinzu. Es bietet auch einen großen Mehrwert, insbesondere im Vergleich zum iFrame-Ansatz. Derzeit gibt es nur begrenzte Häutung. Soweit ich sehen kann, nutzt es fast jeder Benutzer. Fortgeschrittenes Skinning (zB Material Design und Bootstrap4) steht ganz oben auf der Wunschliste der Benutzer, also wird es bald kommen.

Alles in allem bin ich erstaunt, dass Sie so oft das "Re-Skin oder Build"-Bit betonen.

Ich kann mich dem Eindruck nicht erwehren, dass Sie das Projekt ngx-extended-pdf-viewer missbilligen.

Ehrlich gesagt weiß ich nicht einmal, was das Projekt "ngx-extended-pdf-viewer" ist, und werde jetzt, da Weihnachten vor der Tür steht, keine Zeit haben, das herauszufinden, daher habe ich offensichtlich keine Meinung dazu :-)

Im Allgemeinen kein bestimmtes Projekt herausgreifen: Der Grund dafür, dass der Standard-Viewer nicht unverändert verwendet werden sollte, besteht darin, zu vermeiden, dass benutzerdefinierte Anwendungen mit dem integrierten PDF-Viewer in Firefox verwechselt werden, weil sie mehr oder weniger aussehen identisch mit vielen Benutzern.

@Snuffleupagus Danke! Das ist ein sehr guter Grund, mit dem ich arbeiten kann. Ich werde sehen, was ich tun kann, damit "mein" eingebetteter Viewer anders aussieht. In den meisten Fällen sieht es anders aus, einfach weil es kein ganzseitiger Viewer ist, aber natürlich möchte ich meine Fehler nicht auf Ihrem Bugtracker sehen.

Was ich anbieten kann, ist folgendes: Wenn jemand einen Fehlerbericht einreicht und "Angular" erwähnt, einfach CC mich.

Viele Grüße und frohe Weihnachten
Stephan

Das ist sehr nett von dir, danke! Im Allgemeinen erwähnen wir Skinning, weil hier relativ oft Fehler in benutzerdefinierten Bereitstellungen von PDF.js gemeldet wurden, weil Benutzer dachten, sie hätten es mit dem offiziellen Viewer zu tun, obwohl sie tatsächlich eine ungehäutete Kopie des Standard-Viewers betrachteten. Um dies zu vermeiden, erwähnen wir normalerweise diese Zeile, aber in diesem Fall war es nur, um zu zeigen, dass das Erweitern von PDF.js, wie Sie es tun, tatsächlich in Ordnung/empfohlen ist, also keine Sorge!

Wenn Sie Probleme in PDF.js finden, können Sie diese jederzeit melden. Wir haben bereits einige Probleme basierend auf Ihren Problemen/Kommentaren behoben, das ist also sehr hilfreich.