Pdf.js: Fuite de mémoire : certains événements ne sont pas non enregistrés

Merci, je pense que tu as raison. Je ne pense pas qu'il s'agisse nécessairement d'une fuite de mémoire, mais cela devrait être un peu remanié afin que la liaison/déconnexion des événements de fenêtre ne se fasse qu'à un seul endroit.

On dirait que les choses ne sont pas si faciles, même si je ne sais pas encore pourquoi :

• l'écouteur keydown est enregistré lorsque le script viewer.js est chargé, qu'il y ait ou non un PDF.
• J'ai ajouté le removeEventListener comme je l'ai suggéré. A ma grande surprise, CMD+P ne fait rien (sauf mettre en surbrillance le menu "éditer" pendant une fraction de seconde). C'est peut-être un problème d'OSX. Ma théorie est que l'enregistrement de l'événement "keydown" tue automatiquement la liaison de touche standard. Si c'est vrai, nous pourrions simplement le lier à nouveau à window.print() .

BTW, voici mes modifications de code source : https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

Oubliez mon dernier message - j'ai réussi à tout mettre en marche. Il est possible de restaurer la fonctionnalité standard après avoir supprimé pdf.js du DOM. Voir aussi #10948, qui est un effet secondaire inattendu qui m'a dérouté hier.

Dans la demande d'extraction #11380, deux des trois écouteurs d'événements enregistrés sont désormais également désenregistrés lors de la réinitialisation. Seul l'écouteur d'événement print keydown reste pour ce problème.

Dans la demande d'extraction #11380, deux des trois écouteurs d'événements enregistrés sont désormais également désenregistrés lors de la réinitialisation.

Oui, mais ces événements n'ont été corrigés qu'indirectement, car il était logique pour d'autres raisons (telles que la cohérence avec d'autres composants) de permettre la réinitialisation d'une instance PDFHistory .

En général, je serais très tenté de suggérer WONTFIX pour le code PDFPrintService , pour plusieurs raisons :

• Ce problème prétend qu'il y a des fuites de mémoire, mais ne fournit en fait aucune preuve pour le confirmer.
• La seule intégration réellement prise en charge par le visualiseur par défaut est un <iframe> , où je ne peux pas imaginer que ces écouteurs d'événements puissent causer des problèmes.[1]
• Cela n'affecte pas du tout le FirefoxPrintService , car il n'enregistre aucun événement. Par conséquent, essayer de "réparer" cela dans les PDFPrintService rendrait les différentes interfaces PDFPrintServiceFactory "déséquilibrées".
• Il y a un certain nombre d'événements window enregistrés dans web/pdf_print_service.js , et je pense que vous devez les enregistrer immédiatement après le chargement pour ne manquer aucun événement et/ou ne pas être le premier gestionnaire d'événements. Par conséquent, la suppression de ces écouteurs d'événement peut entraîner un comportement inattendu par la suite.

[1] Notez également http://mozilla.github.io/pdf.js/getting_started/#introduction (c'est moi qui souligne) :

La visionneuse est construite sur la couche d'affichage et constitue l'interface utilisateur de la visionneuse PDF dans Firefox et les autres extensions de navigateur au sein du projet. Cela peut être un bon point de départ pour créer votre propre visionneuse. Cependant, nous vous demandons si vous envisagez d'intégrer la visionneuse dans votre propre site, qu'il ne s'agisse pas simplement d'une version non modifiée.

@Snuffleupagus Je ne peux pas échapper à l'impression que vous désapprouvez le projet ngx-extended-pdf-viewer. Est-ce correct? Si oui, pourquoi?

Juste pour mémoire : ngx-extended-pdf-viewer s'appuie sur pdf.js. Il ajoute 62 modifications aux fichiers de base pdf.js. Cela ajoute également beaucoup de valeur supplémentaire, en particulier par rapport à l'approche iFrame. Actuellement, le skinning est limité. Autant que je sache, presque tous les utilisateurs l'utilisent. Le skinning avancé (c'est-à-dire Material Design et Bootstrap4) est en haut de la liste de souhaits des utilisateurs, il viendra donc bientôt.

En mettant tout cela ensemble, je suis étonné que vous insistiez si souvent sur le "re-skin or build".

Je ne peux pas échapper à l'impression que vous désapprouvez le projet ngx-extended-pdf-viewer.

Honnêtement, je ne sais même pas ce qu'est le projet "ngx-extended-pdf-viewer", et je n'aurai pas le temps de le comprendre maintenant avec Noël qui approche à grands pas, donc je n'ai évidemment pas d'opinion à ce sujet :-)

De manière générale, ne pas distinguer un projet particulier : la raison pour laquelle la visionneuse par défaut ne doit pas être utilisée telle

@Snuffleupagus Merci ! C'est une très bonne raison, quelque chose avec laquelle je peux travailler. Je vais voir ce que je peux faire pour que "ma" visionneuse intégrée soit différente. Dans la plupart des cas, cela sera différent simplement parce que ce n'est pas une visionneuse pleine page, mais bien sûr, je ne veux pas voir mes bugs sur votre bug tracker.

Ce que je peux offrir, c'est ceci : si quelqu'un dépose un rapport de bogue et mentionne "Angular", il suffit de me mettre en CC.

Bien cordialement et joyeux Noël
Stéphan

C'est très gentil de ta part, merci ! En général, nous mentionnons le skinning car nous avons vu des bogues dans les déploiements personnalisés de PDF.js signalés ici relativement souvent parce que les utilisateurs pensaient avoir affaire à la visionneuse officielle alors qu'ils regardaient en fait une copie sans peau de la visionneuse par défaut. Pour éviter cela, nous mentionnons généralement cette ligne, mais dans ce cas, c'était juste pour montrer que l'extension de PDF.js comme vous le faites est en fait OK/recommandée, donc ne vous inquiétez pas !

Si vous rencontrez des problèmes dans PDF.js, n'hésitez pas à toujours les signaler. Nous avons déjà résolu certains problèmes en fonction de vos problèmes/commentaires, c'est donc très utile.