Pdf.js: Pérdida de memoria: algunos eventos no están registrados

Gracias, creo que tienes razón. No creo que sea necesariamente una pérdida de memoria, pero esto debería refactorizarse un poco para que la vinculación / desvinculación de los eventos de ventana esté en un solo lugar.

Parece que las cosas no son tan fáciles, aunque todavía no sé por qué:

• el oyente keydown se registra cuando se carga el script viewer.js, sin importar si hay un PDF o no.
• Agregué removeEventListener como sugerí. Para mi sorpresa, CMD + P no hace nada (excepto resaltar el menú "editar" por una fracción de segundo). Quizás sea un problema de OSX. Mi teoría es que registrar el evento "keydown" mata automáticamente la vinculación de teclas estándar. Si eso es cierto, simplemente podríamos volver a vincularlo a window.print() .

Por cierto, aquí están mis cambios en el código fuente: https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

Olvídate de mi última publicación, me las arreglé para poner todo en funcionamiento. Es posible restaurar la funcionalidad estándar después de eliminar pdf.js del DOM. También vea el número 10948, que es un efecto secundario inesperado que me confundió ayer.

En la solicitud de extracción n. ° 11380, dos de los tres detectores de eventos registrados ahora también se anulan al reiniciar. Para este problema, solo queda el detector de eventos print keydown.

En la solicitud de extracción n. ° 11380, dos de los tres detectores de eventos registrados ahora también se anulan al reiniciar.

Sí, pero esos eventos solo se corrigieron indirectamente, ya que tenía sentido por otras razones (como la coherencia con otros componentes) para permitir que se restableciera una instancia PDFHistory .

En general, aunque estaría muy tentado de sugerir WONTFIX para el código PDFPrintService , por un par de razones:

• Este problema afirma que hay pérdidas de memoria, pero en realidad no proporciona ninguna evidencia que lo respalde.
• La única incrustación que el visor predeterminado realmente admite es un <iframe> , donde no puedo imaginar que estos oyentes de eventos causen problemas. [1]
• Esto no afecta el FirefoxPrintService en absoluto, ya que no registra eventos. Por lo tanto, tratar de "arreglar" esto en PDFPrintService haría que las diferentes interfaces PDFPrintServiceFactory "no estén equilibradas".
• Hay una serie de eventos window registrados en web/pdf_print_service.js , y creo que debe registrarlos inmediatamente después de la carga para no perderse ningún evento y / o no ser el primer controlador de eventos. En consecuencia, la eliminación de estos detectores de eventos puede dar lugar a un comportamiento inesperado más adelante.

[1] Tenga en cuenta también http://mozilla.github.io/pdf.js/getting_started/#introduction (el énfasis es mío):

El visor se basa en la capa de visualización y es la interfaz de usuario para el visor de PDF en Firefox y las otras extensiones del navegador dentro del proyecto. Puede ser un buen punto de partida para crear su propio visor. Sin embargo, le preguntamos si planea incrustar el visor en su propio sitio, que no sea solo una versión sin modificar.

@Snuffleupagus No puedo evadir la impresión de que desapruebas el proyecto ngx-extended-pdf-viewer. ¿Es esto correcto? Si es así, ¿por qué?

Solo para el registro: ngx-extended-pdf-viewer se basa en pdf.js. Agrega 62 modificaciones a los archivos principales pdf.js. También agrega mucho valor adicional, especialmente en comparación con el enfoque iFrame. Actualmente, hay desollado limitado. Por lo que puedo ver, casi todos los usuarios lo están usando. La máscara avanzada (es decir, Material Design y Bootstrap4) está en la parte superior de la lista de deseos de los usuarios, por lo que llegará pronto.

Poniéndolo todo junto, me sorprende que hagas hincapié en la parte de "volver a revestir o construir" con tanta frecuencia.

No puedo evitar la impresión de que desapruebas el proyecto ngx-extended-pdf-viewer.

Honestamente, ni siquiera sé qué es el proyecto "ngx-extended-pdf-viewer", y no tendré tiempo para averiguarlo ahora con la Navidad a la vuelta de la esquina, por lo que obviamente no tengo una opinión al respecto. :-)

En términos generales, sin destacar ningún proyecto en particular: la razón por la que el visor predeterminado no debe usarse tal como está, es para evitar que las aplicaciones personalizadas se confundan con el visor de PDF incorporado en Firefox en virtud de que se ven más o menos idéntico a muchos usuarios.

@Snuffleupagus ¡Gracias! Esa es una muy buena razón, algo con lo que puedo trabajar. Veré qué puedo hacer para que "mi" visor incorporado se vea diferente. En la mayoría de los casos, se verá diferente simplemente porque no es un visor de página completa, pero por supuesto, no quiero ver mis errores en su rastreador de errores.

Lo que puedo ofrecer es esto: si alguien presenta un informe de error y menciona "Angular", simplemente CC.

Saludos cordiales y feliz Navidad
Stephan

Eso es muy amable de tu parte, ¡gracias! En general, mencionamos el skinning porque hemos visto errores en las implementaciones personalizadas de PDF.js que se informan aquí con relativa frecuencia porque los usuarios pensaron que estaban tratando con el visor oficial cuando en realidad estaban viendo una copia sin skin del visor predeterminado. Para evitar esto, generalmente mencionamos esta línea, pero en este caso fue solo para mostrar que extender PDF.js como lo está haciendo está realmente bien / recomendado, ¡así que no se preocupe por eso!

Si encuentra problemas en PDF.js, no dude en informarlos siempre. Ya hemos solucionado algunos problemas en función de sus problemas / comentarios, por lo que es muy útil.