Pdf.js: 메모리 누수: 일부 이벤트가 등록 취소되지 않았습니다.

감사합니다. 제 생각이 맞습니다. 나는 그것이 반드시 메모리 누수라고 생각하지는 않지만 윈도우 이벤트의 바인딩/바인딩 해제가 한 곳에서만 이루어지도록 약간 리팩토링해야 합니다.

아직 이유는 모르지만 상황이 그렇게 쉽지는 않은 것 같습니다.

• keydown 리스너는 PDF가 있든 없든 간에 viewer.js 스크립트가 로드될 때 등록됩니다.
• 제안한 대로 removeEventListener를 추가했습니다. 놀랍게도 CMD+P는 아무 것도 하지 않습니다("편집" 메뉴를 잠시 강조 표시하는 것 제외). 아마도 그것은 OSX 문제 일 것입니다. 내 이론은 "keydown" 이벤트를 등록하면 표준 키 바인딩이 자동으로 종료된다는 것입니다. 그것이 사실이라면 간단히 window.print() 다시 바인딩할 수 있습니다.

BTW, 여기 내 소스 코드 변경은 다음과 같습니다 https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff -ff2d4af1f0673e3ea448a4b444ece1da

내 마지막 게시물은 잊어버리세요. 모든 것을 시작하고 실행하는 데 성공했습니다. DOM에서 pdf.js를 제거한 후 표준 기능을 복원할 수 있습니다. 어제 나를 혼란스럽게 만든 예상치 못한 부작용인 #10948도 참조하십시오.

pull request #11380에서 등록된 이벤트 리스너 3개 중 2개도 이제 재설정 시 등록 취소됩니다. 이 문제에 대해서는 print keydown 이벤트 리스너만 남아 있습니다.

pull request #11380에서 등록된 이벤트 리스너 3개 중 2개도 이제 재설정 시 등록 취소됩니다.

예, 하지만 이러한 이벤트는 PDFHistory 인스턴스를 재설정할 수 있도록 하는 다른 이유(예: 다른 구성 요소와의 일관성)가 합리적이기 때문에 간접적으로만 수정되었습니다.

그러나 일반적으로 나는 매우를 위해 고치지 않을 것 (wontfix)을 제안 유혹 할 것이다 PDFPrintService 몇 가지 이유를 들어, 코드 :

• 이 문제는 메모리 누수가 있다고 주장하지만 실제로 이를 뒷받침할 증거는 제공하지 않습니다.
• 기본 뷰어가 실제로 지원하는 유일한 임베딩은 <iframe> . 여기서 이러한 이벤트 리스너가 문제를 일으킬 것이라고는 상상할 수 없습니다.[1]
• 이것은 이벤트를 등록하지 않기 때문에 FirefoxPrintService 에 전혀 영향을 미치지 않습니다. 따라서 PDFPrintService 에서 이것을 "수정"하려고 하면 다른 PDFPrintServiceFactory 인터페이스가 "불균형"이 됩니다.
• 이 다수의 window 에 등록 이벤트 web/pdf_print_service.js , 그리고 당신이 첫 번째 이벤트 핸들러되는 모든 이벤트 및 / 또는하지를 놓치지에 부하에 즉시 등록해야한다고 생각합니다. 따라서, 이러한 이벤트 리스너를 제거하는 것은 따라서 나중에 예기치 않은 동작이 발생할 수 있습니다.

[1] http://mozilla.github.io/pdf.js/getting_started/#introduction 참고(강조 광산):

뷰어는 디스플레이 레이어에 구축되며 Firefox의 PDF 뷰어 및 프로젝트 내의 기타 브라우저 확장을 위한 UI입니다. 자신만의 뷰어를 구축하기 위한 좋은 출발점이 될 수 있습니다. 그러나 수정되지 않은 버전이 아니라 귀하의 사이트에 뷰어를 포함할 계획인지 묻습니다.

@Snuffleupagus 나는 당신이 ngx-extended-pdf-viewer 프로젝트를 승인하지 않는다는 인상을 피할 수 없습니다. 이 올바른지? 그렇다면 왜?

기록을 위해: ngx-extended-pdf-viewer는 pdf.js를 기반으로 합니다. 핵심 pdf.js 파일에 62개의 수정 사항을 추가합니다. 또한 특히 iFrame 접근 방식과 비교할 때 많은 추가 가치를 추가합니다. 현재 제한된 스키닝이 있습니다. 내가 볼 수있는 한 거의 모든 사용자가 사용하고 있습니다. 고급 스키닝(예: Material Design 및 Bootstrap4)은 사용자의 위시리스트 상단에 있으므로 곧 제공될 것입니다.

이 모든 것을 종합해보면, 당신이 "리스킨 또는 빌드"를 너무 자주 강조한다는 사실에 놀랐습니다.

나는 당신이 ngx-extended-pdf-viewer 프로젝트를 승인하지 않는다는 인상을 피할 수 없습니다.

솔직히 나는 "ngx-extended-pdf-viewer" 프로젝트가 무엇인지도 모르고, 크리스마스가 얼마 남지 않은 지금 그것을 알아낼 시간이 없을 것입니다. 따라서 분명히 그것에 대한 의견이 없습니다. :-)

일반적으로 특정 프로젝트를 선택하지 않음: 기본 뷰어를 그대로 사용하면 안 되는 이유는 사용자 정의 응용 프로그램이 Firefox의 내장 PDF 뷰어로 오인되는 것을 방지하기 위함입니다. 많은 사용자와 동일합니다.

@Snuffleupagus 감사합니다! 그것은 내가 일할 수 있는 아주 좋은 이유입니다. "내" 내장 뷰어를 다르게 보이게 하려면 어떻게 해야 하는지 알아보겠습니다. 대부분의 경우 전체 페이지 뷰어가 아니기 때문에 다르게 보일 수 있지만 물론 버그 추적기에서 내 버그를 보고 싶지는 않습니다.

내가 제안할 수 있는 것은 다음과 같습니다. 누군가 버그 보고서를 제출하고 "Angular"를 언급하면 ​​저를 참조하세요.

안부 인사, 그리고 메리 크리스마스
스테판

당신의 아주 좋은, 감사합니다! 일반적으로 사용자가 실제로 기본 뷰어의 스킨이 없는 복사본을 보고 있을 때 공식 뷰어를 다루고 있다고 생각했기 때문에 여기에 상대적으로 자주 보고되는 PDF.js의 사용자 정의 배포 버그를 보았기 때문에 스키닝을 언급합니다. 이것을 피하기 위해 우리는 일반적으로 이 줄을 언급하지만 이 경우에는 PDF.js를 확장하는 것이 실제로 OK/권장됨을 보여주기 위한 것이므로 걱정할 필요가 없습니다!

PDF.js에서 문제를 발견하면 언제든지 언제든지 보고해 주십시오. 귀하의 문제/의견을 기반으로 일부 문제를 이미 수정했으므로 매우 유용합니다.