Pdf.js: Kebocoran memori: beberapa acara tidak terdaftar

Terima kasih, saya pikir Anda benar. Saya tidak berpikir itu pasti kebocoran memori, tetapi ini harus di-refactored sedikit sehingga pengikatan/pemutusan ikatan peristiwa jendela hanya di satu tempat.

Tampaknya hal-hal tidak begitu mudah, meskipun saya belum tahu mengapa:

• pendengar keydown terdaftar ketika skrip viewer.js dimuat, tidak peduli apakah ada PDF atau tidak.
• Saya telah menambahkan removeEventListener seperti yang saya sarankan. Yang mengejutkan saya, CMD+P tidak melakukan apa pun (kecuali menyorot menu "edit" selama sepersekian detik). Mungkin itu masalah OSX. Teori saya adalah bahwa mendaftarkan acara "keydown" secara otomatis mematikan pengikatan kunci standar. Jika itu benar, kita cukup mengikatnya kembali ke window.print() .

BTW, berikut adalah perubahan kode sumber saya: https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

Lupakan posting terakhir saya - saya telah berhasil mendapatkan semuanya dan berjalan. Dimungkinkan untuk memulihkan fungsionalitas standar setelah menghapus pdf.js dari DOM. Lihat juga #10948, yang merupakan efek samping tak terduga yang membuat saya bingung kemarin.

Dalam permintaan tarik #11380 dua dari tiga pendengar acara terdaftar sekarang juga tidak terdaftar setelah mengatur ulang. Hanya pendengar acara keydown cetak yang tersisa untuk masalah ini.

Dalam permintaan tarik #11380 dua dari tiga pendengar acara terdaftar sekarang juga tidak terdaftar setelah mengatur ulang.

Ya, tetapi peristiwa itu hanya diperbaiki secara tidak langsung karena masuk akal karena alasan lain (seperti konsistensi dengan komponen lain) untuk memungkinkan instance PDFHistory disetel ulang.

Namun secara umum saya akan sangat tergoda untuk menyarankan WONTFIX untuk kode PDFPrintService , karena beberapa alasan:

• Masalah ini mengklaim bahwa ada kebocoran memori, tetapi sebenarnya tidak memberikan bukti apa pun untuk mendukungnya.
• Satu-satunya penyematan yang benar-benar didukung oleh penampil default adalah <iframe> , di mana saya tidak dapat membayangkan bahwa pendengar acara ini akan menyebabkan masalah.[1]
• Ini tidak mempengaruhi FirefoxPrintService sama sekali, karena tidak mencatat acara. Oleh karena itu mencoba untuk "memperbaiki" ini di PDFPrintService dengan demikian akan membuat antarmuka PDFPrintServiceFactory "tidak seimbang".
• Ada sejumlah acara window yang didaftarkan di web/pdf_print_service.js , dan saya pikir Anda harus mendaftarkannya segera setelah dimuat agar tidak melewatkan acara apa pun dan/atau tidak menjadi pengendali acara pertama . Akibatnya, menghapus pendengar acara ini dapat menyebabkan perilaku yang tidak terduga di kemudian hari.

[1] Perhatikan juga http://mozilla.github.io/pdf.js/getting_started/#introduction (penekanan milik saya):

Penampil dibangun di lapisan tampilan dan merupakan UI untuk penampil PDF di Firefox dan ekstensi browser lainnya dalam proyek. Ini bisa menjadi titik awal yang baik untuk membangun penampil Anda sendiri. Namun, kami bertanya apakah Anda berencana untuk menyematkan penampil di situs Anda sendiri, bahwa itu bukan hanya versi yang tidak dimodifikasi.

@Snuffleupagus Saya tidak dapat menghindari kesan bahwa Anda tidak menyetujui proyek ngx-extended-pdf-viewer. Apakah ini benar? Jika demikian, mengapa?

Sebagai catatan: ngx-extended-pdf-viewer dibangun di atas pdf.js. Itu menambahkan 62 modifikasi ke file pdf.js inti. Ini juga menambahkan banyak nilai tambahan, terutama dibandingkan dengan pendekatan iFrame. Saat ini, ada skin yang terbatas. Sejauh yang saya lihat, hampir setiap pengguna menggunakannya. Skinning tingkat lanjut (yaitu Desain Material dan Bootstrap4) ada di atas daftar keinginan pengguna, jadi itu akan segera hadir.

Menyatukan semuanya, saya heran Anda begitu sering menekankan "kulit ulang atau bangun".

Saya tidak dapat menghindari kesan bahwa Anda tidak menyetujui proyek ngx-extended-pdf-viewer.

Sejujurnya saya bahkan tidak tahu apa proyek "ngx-extended-pdf-viewer", dan tidak akan punya waktu untuk mengetahuinya sekarang dengan Natal yang sudah dekat, maka saya jelas tidak memiliki pendapat tentang itu :-)

Secara umum, tidak memilih proyek tertentu: Alasan bahwa penampil default tidak boleh digunakan apa adanya, adalah untuk menghindari aplikasi khusus disalahartikan sebagai Penampil PDF bawaan di Firefox berdasarkan tampilan lebih-atau-kurang identik dengan banyak pengguna.

@Snuffleupagus Terima kasih! Itu alasan yang sangat bagus, sesuatu yang bisa saya kerjakan. Saya akan melihat apa yang dapat saya lakukan untuk membuat penampil tersemat "saya" terlihat berbeda. Dalam kebanyakan kasus, itu akan terlihat berbeda hanya karena ini bukan penampil satu halaman penuh, tetapi tentu saja, saya tidak ingin melihat bug saya di pelacak bug Anda.

Yang dapat saya tawarkan adalah ini: jika seseorang mengajukan laporan bug, dan menyebutkan "Angular", cukup CC saya.

Salam hangat, dan selamat Natal
Stefanus

Itu sangat baik dari Anda, terima kasih! Secara umum kami menyebutkan skinning karena kami telah melihat bug dalam penerapan kustom PDF.js dilaporkan di sini relatif sering karena pengguna mengira mereka berurusan dengan penampil resmi padahal mereka sebenarnya melihat salinan penampil default yang tidak dikuliti. Untuk menghindari hal ini, kami biasanya menyebutkan baris ini, tetapi dalam kasus ini hanya untuk menunjukkan bahwa memperluas PDF.js seperti yang Anda lakukan sebenarnya OK/disarankan, jadi jangan khawatir tentang itu!

Jika Anda menemukan masalah di PDF.js, jangan ragu untuk selalu melaporkannya. Kami telah memperbaiki beberapa masalah berdasarkan masalah/komentar Anda, jadi itu sangat membantu.