Pdf.js: メモリリーク:一部のイベントは登録解除されていません

作成日 2019年07月05日  ·  9コメント  ·  ソース: mozilla/pdf.js

構成:

  • Webブラウザとそのバージョン:任意のバージョン
  • オペレーティングシステムとそのバージョン:任意のOS
  • PDF.jsバージョン:2.2.222
  • ブラウザ拡張機能です:いいえ(Webアプリケーションに埋め込まれたPDFを表示するために汎用ブラウザを使用しています)

https://github.com/stephanrauh/ngx-extended-pdf-viewer/issues/101を調査しているときに、登録されているが登録解除されていないイベントが3つあることに気付きました。 それはメモリリークだと思います。 私の場合、PDFビューアを使用してページを離れた後、CTRL + Pで印刷しようとすると、SPAで問題が発生します。

  • window.addEventListener( 'keydown'、function(event){ここで定義
  • window.addEventListener( 'popstate'、_ boundEvents.popState); ここで定義
  • window.addEventListener( 'pagehide'、_ boundEvents.pageHide); ここで定義

これらの3つのイベントをPDFViewerApplication.unbindWindowEvents()に追加するだけの問題だと思います。

1-viewer

全てのコメント9件

ありがとう、私はあなたが正しいと思います。 必ずしもメモリリークだとは思いませんが、ウィンドウイベントのバインド/バインド解除が1か所だけになるように少しリファクタリングする必要があります。

理由はまだわかりませんが、物事はそれほど簡単ではないようです。

  • キーダウンリスナーは、PDFの有無に関係なく、viewer.jsスクリプトが読み込まれるときに登録されます。
  • 提案したように、removeEventListenerを追加しました。 驚いたことに、CMD + Pは何もしません(「編集」メニューをほんの一瞬だけ強調表示することを除いて)。 多分それはOSXの問題です。 私の理論では、「keydown」イベントを登録すると、標準のキーバインディングが自動的に強制終了されます。 それが本当なら、それをwindow.print()再バインドするだけで済みます。

ところで、ここに私のソースコードの変更があります: https

私の最後の投稿を忘れてください-私はなんとかすべてを稼働させることができました。 DOMからpdf.jsを削除した後、標準機能を復元することが可能です。 昨日私を混乱させた予期しない副作用である#10948も参照してください。

プルリクエスト#11380では、登録されている3つのイベントリスナーのうち2つも、リセット時に登録解除されます。 この問題については、印刷キーダウンイベントリスナーのみが残ります。

プルリクエスト#11380では、登録されている3つのイベントリスナーのうち2つも、リセット時に登録解除されます。

はい。ただし、他の理由(他のコンポーネントとの整合性など)でPDFHistoryインスタンスをリセットできるようにすることが理にかなっているため、これらのイベントは間接的にのみ修正されました。

一般的に私は非常にためにWONTFIXを示唆するように誘惑されるだろうけれどもPDFPrintService理由のカップルのために、コード:

  • この問題は、メモリリークがあると主張していますが、実際にはそれを裏付ける証拠を提供していません。
  • デフォルトのビューアが実際にサポートしている唯一の埋め込みは<iframe>であり、これらのイベントリスナーが問題を引き起こすとは想像できません。[1]
  • イベントを登録しないため、これはFirefoxPrintServiceはまったく影響しません。 したがって、これをPDFPrintServiceで「修正」しようとすると、さまざまなPDFPrintServiceFactoryインターフェイスが「不均衡」になります。
  • web/pdf_print_service.jsには多数windowイベントが登録されており、イベントを見逃したり、最初のイベントハンドラーになったりしないように、ロード後すぐに登録する必要があると思います。 したがって、これらのイベントリスナーを削除すると、後で予期しない動作が発生する可能性があります。

[1] http://mozilla.github.io/pdf.js/getting_started/#introduction (私の強調)にも注意して

ビューアはディスプレイレイヤー上に構築されており、Firefoxおよびプロジェクト内の他のブラウザ拡張機能のPDFビューアのUIです。 これは、独自のビューアを構築するための良い出発点になる可能性があります。 ただし、ビューアを自分のサイトに埋め込む予定があるかどうかは、変更されていないバージョンだけではないことをお勧めします。

@ Snuffleupagusngx-extended-pdf-viewerプロジェクトに対するあなたの不承認の印象を回避することはできません。 これは正しいです? もしそうなら、なぜですか?

念のために言っておきますが、ngx-extended-pdf-viewerはpdf.jsに基づいて構築されています。 コアpdf.jsファイルに62の変更を追加します。 また、特にiFrameアプローチと比較して、多くの付加価値を追加します。 現在、スキニングは限られています。 私が見る限り、ほとんどすべてのユーザーがそれを使用しています。 高度なスキニング(つまり、マテリアルデザインとBootstrap4)はユーザーのウィッシュリストの一番上にあるので、まもなく登場します。

すべてをまとめると、「スキンの変更またはビルド」を頻繁に強調することに驚いています。

ngx-extended-pdf-viewerプロジェクトに対するあなたの不承認の印象を回避することはできません。

正直なところ、「ngx-extended-pdf-viewer」プロジェクトが何であるかさえ知らず、クリスマスが間近に迫っている今、それを理解する時間がないので、明らかにそれについての意見はありません。 :-)


一般的に言って、特定のプロジェクトを選び出さないでください。デフォルトのビューアをそのまま使用しない理由は、多かれ少なかれ見た目が原因で、カスタムアプリケーションがFirefoxの組み込みPDFビューアと間違われるのを防ぐためです。多くのユーザーと同じです。

@Snuffleupagusありがとう! それは非常に正当な理由であり、私が取り組むことができるものです。 「自分の」埋め込みビューアの外観を変えるために何ができるかを見ていきます。 ほとんどの場合、フルページビューアではないという理由だけで外観が異なりますが、もちろん、バグトラッカーでバグを確認したくありません。

私が提供できるのはこれです:誰かがバグレポートを提出し、「Angular」に言及した場合は、CCしてください。

よろしく、そしてメリークリスマス
ステファン

よろしくお願いします! 一般に、スキニングについて言及します。これは、PDF.jsのカスタム展開のバグが比較的頻繁に報告されているためです。これは、ユーザーが実際にはスキンのないデフォルトビューアーのコピーを見ているときに、公式ビューアーを扱っていると思ったためです。 これを避けるために、私たちは通常この行に言及しますが、この場合、あなたがしているようにPDF.jsを拡張することは実際にOK /推奨されることを示すためだけでしたので、それについて心配する必要はありません!

PDF.jsで問題を見つけた場合は、いつでも気軽に報告してください。 私たちはあなたの問題/コメントに基づいてすでにいくつかの問題を修正しているので、それは非常に役に立ちます。

このページは役に立ちましたか?
0 / 5 - 0 評価