Pdf.js: Vazamento de memória: alguns eventos não são registrados

Obrigado, acho que você está certo. Não acho que seja necessariamente um vazamento de memória, mas isso deve ser um pouco refatorado para que a vinculação / desvinculação de eventos de janela esteja em apenas um lugar.

Parece que as coisas não são tão fáceis, embora ainda não saiba por quê:

• o listener keydown é registrado quando o script viewer.js é carregado, não importa se há um PDF ou não.
• Eu adicionei o removeEventListener como sugeri. Para minha surpresa, o CMD + P não faz nada (exceto destacar o menu "editar" por uma fração de segundo). Talvez seja um problema OSX. Minha teoria é que registrar o evento "keydown" mata automaticamente a ligação de tecla padrão. Se isso for verdade, poderíamos simplesmente ligá-lo novamente a window.print() .

BTW, aqui estão minhas alterações no código-fonte: https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

Esqueça minha última postagem - consegui colocar tudo em funcionamento. É possível restaurar a funcionalidade padrão após remover o pdf.js do DOM. Veja também # 10948, que é um efeito colateral inesperado que me confundiu ontem.

Na solicitação pull nº 11380, dois dos três ouvintes de evento registrados agora também não estão registrados após a reinicialização. Apenas o listener de evento de keydown de impressão permanece para esse problema.

Na solicitação pull nº 11380, dois dos três ouvintes de evento registrados agora também não estão registrados após a reinicialização.

Sim, mas esses eventos foram corrigidos apenas indiretamente, pois fazia sentido por outros motivos (como consistência com outros componentes) permitir que uma instância PDFHistory fosse redefinida.

Em geral, porém, ficaria muito tentado a sugerir WONTFIX para o código PDFPrintService , por alguns motivos:

• Este problema afirma que há vazamentos de memória, mas não fornece nenhuma evidência para fazer o backup.
• A única incorporação que o visualizador padrão realmente suporta é um <iframe> , onde não posso imaginar que esses ouvintes de evento devam causar problemas. [1]
• Isso não afeta o FirefoxPrintService alguma, uma vez que ele não registra nenhum evento. Portanto, tentar "consertar" isso em PDFPrintService tornaria as diferentes PDFPrintServiceFactory interfaces "desequilibradas".
• Há vários eventos window sendo registrados em web/pdf_print_service.js , e eu acho que você precisa registrá-los imediatamente após o carregamento para não perder nenhum evento e / ou não ser o primeiro manipulador de eventos. Conseqüentemente, a remoção desses ouvintes de eventos pode levar a um comportamento inesperado posteriormente.

[1] Observe também http://mozilla.github.io/pdf.js/getting_started/#introduction (ênfase minha):

O visualizador é construído na camada de exibição e é a IU para visualizador de PDF no Firefox e outras extensões de navegador dentro do projeto. Pode ser um bom ponto de partida para construir seu próprio visualizador. No entanto, perguntamos se você planeja incorporar o visualizador em seu próprio site, para que não seja apenas uma versão não modificada.

@Snuffleupagus Não posso evitar a impressão que você desaprova o projeto ngx-extended-pdf-viewer. Isso está correto? Se sim, por quê?

Apenas para registro: ngx-extended-pdf-viewer é baseado em pdf.js. Ele adiciona 62 modificações aos arquivos pdf.js principais. Ele também agrega muito valor adicional, especialmente em comparação com a abordagem iFrame. Atualmente, há esfola limitada. Pelo que posso ver, quase todos os usuários o estão usando. Skinning avançado (ou seja, Material Design e Bootstrap4) está no topo da lista de desejos dos usuários, então virá em breve.

Juntando tudo isso, estou surpreso que você enfatize a parte "refazer a pele ou construir" com tanta frequência.

Não posso evitar a impressão de que você desaprova o projeto ngx-extended-pdf-viewer.

Honestamente, eu nem sei o que é o projeto "ngx-extended-pdf-viewer" e não terei tempo para descobrir isso agora com o Natal chegando, portanto, obviamente, não tenho uma opinião sobre ele :-)

De modo geral, sem destacar nenhum projeto em particular: O motivo pelo qual o visualizador padrão não deve ser usado no estado em que se encontra é para evitar que os aplicativos personalizados sejam confundidos com o visualizador de PDF integrado no Firefox por causa da aparência mais ou menos idêntico a muitos usuários.

@Snuffleupagus Obrigado! Essa é uma razão muito boa, algo com que posso trabalhar. Vou ver o que posso fazer para tornar o "meu" visualizador incorporado diferente. Na maioria dos casos, ele parecerá diferente simplesmente porque não é um visualizador de página inteira, mas é claro, não quero ver meus bugs em seu rastreador de bug.

O que posso oferecer é o seguinte: se alguém enviar um relatório de bug e mencionar "Angular", basta enviar-me por cópia.

Atenciosamente, e Feliz Natal
Stephan

Isso é muito legal da sua parte, obrigado! Em geral, mencionamos o skinning porque vimos bugs em implantações customizadas de PDF.js sendo relatados aqui com relativa frequência, porque os usuários pensaram que estavam lidando com o visualizador oficial quando, na verdade, estavam olhando para uma cópia sem skin do visualizador padrão. Para evitar isso, geralmente mencionamos esta linha, mas neste caso foi apenas para mostrar que estender PDF.js como você está fazendo é realmente OK / recomendado, então não se preocupe com isso!

Se você encontrar problemas no PDF.js, sinta-se à vontade para relatá-los sempre. Já corrigimos alguns problemas com base em seus problemas / comentários, o que é muito útil.