Pdf.js: Angular + pdf.jsのIE11互換性を有効にする

作成日 2017年03月24日  ·  10コメント  ·  ソース: mozilla/pdf.js

構成:

  • Webブラウザとそのバージョン:IE 11
  • オペレーティングシステムとそのバージョン:任意
  • PDF.jsバージョン:1.4.0
  • AngularJsバージョン:1.5.11

問題を再現する手順:

  1. 自動ブートストラップでAngularJS1.5.11を使用する
  2. Angularのスクリプトタグの前にPDF.jsバージョン1.4.0を含めます

期待される動作は何ですか? (スクリーンショットを追加)

  • AngularはPDF.jsと完全に連携します
  • PDF.jsは、不足しているAPIを、ネイティブバージョンが利用できない場合にシムバージョンを使用する関数にラップします。

何が悪かったのか? (スクリーンショットを追加)

  • https://github.com/angular/angular.js/issues/15772を参照して
    現在、pdf.jsはdocument.currentScriptを定義していますが、link.originやlink.protocolは定義していません。 角度が開始すると、自動的にブートストラップが許可されているかどうかがチェックされ、currentScriptがチェックされ、IEをフィルタリングするのに十分であると想定されます。つまり、currentScriptが定義されていない場合は、自動的にブートストラップできます。 このチェックは、pdf.jsとの組み合わせでは機能しません。

ライブラリは、このような問題を引き起こすため、所有していないオブジェクトのプロパティを変更しないでください。 サポートされている一部の環境で欠落している特定のAPIが必要な場合は、ネイティブバージョンが利用できない場合に、シムバージョンを使用する関数でその使用法をラップすることがあります。

ビューアへのリンク(mozilla.github.io/pdf.js以外のサイトでホストされている場合、またはFirefox / Chrome拡張機能としてホストされている場合):
http://plnkr.co/edit/YFCQM2Px0QU0KnGzsAlM?p=preview

1-other

全てのコメント10件

ややIE11から非難をシフトしているように聞こえます-不完全なセキュリティチェックAngularロジックからPDF.jsポリフィル...わかりました。 このギャップを修正するための単純なバグとしてマークする:

  1. 'origin'プロパティがない場合は、 document.location.originを新しいURL(document.location.href).originに設定する必要があります
  2. HTMLScriptElement.prototypeは、上記と同様のロジックを持つオリジンゲッターとプロトコルゲッターが必要です。

@yurydelendik私にとって、これは、MooToolsが部分的なポリフィルを適用していて、それに応じてWeb上のコードが開始されたため、いくつかのWebAPIが名前を変更しなければならなかった状況に似ています。

ポリフィルは危険です。IMOは完全なポリフィルでのみ実行し、ライブラリではなく最終的なアプリでのみ実行する必要があります。 ライブラリがどこでも利用できない特定のAPIを必要とする場合は、ネイティブAPIをユーティリティ関数でラップし、その関数を使用する必要があります。 これにより、このような考えられるバグのクラス全体が削除されます。

つまり、ライブラリコードは、ネイティブブラウザグローバルなど、所有していないオブジェクトを変更してはなりません。

ポリフィリングは危険です

@mgolああ、同意します。 PDF.jsビューアアプリケーション全体を独自のサンドボックス(iframeをお勧めします)に配置する必要がありますが、人々はそれをより大きなアプリ内で使用し続けます。 したがって、それに応じて対応する必要があります。

ライブラリコードは、ネイティブブラウザグローバルなど、所有していないオブジェクトを変更しないでください。

別の例を見てみましょう。型付き配列がないと、 Promise PDF.jsライブラリは同じではありません。 また、グローバルオブジェクトを変更しないことで、コードが判読できなくなり、最近のブラウザの大部分でパフォーマンスが低下する可能性があります。

別の例を見てみましょう。型付き配列がないと、PromisePDF.jsライブラリは同じではありません。 また、グローバルオブジェクトを変更しないことで、コードが判読できなくなり、最近のブラウザの大部分でパフォーマンスが低下する可能性があります。

必ずしも。 グローバルをシャドウする独自の内部変数セットを保持できます。 これはすべてのケースをカバーするわけではありませんが、少なくとも約束は問題ないはずです。 何かのようなもの:

var Promise = window.Promise || PROMISE_POLYFILL;

PDF.jsの上部にあります。 その場合、グローバルに触れることはなく、コードでPromiseを変更せずに使用できます。

これは、最新のブラウザの単純なエイリアスであるため、パフォーマンスに影響を与えることはありません。

ただし、すべての場合でそれほど簡単ではない可能性があることは理解しています(たとえば、いくつかのメソッドのみをポリフィルする必要がある場合)

PDF.jsコードは、ES6モジュールを使用するように変換されています。 上記のアプローチは、パッケージャーが自動的にポリフィルを提供しない限り、問題のあるATMになる可能性があります。

この問題をAngularロジックやpdf.js互換性アプローチについての議論に変えたくありません。私たちのポリフィルを修正して、Angularでうまくプレイできるようにするといいでしょう。 PRは大歓迎です:)

別の考えでは、修正されないので、この問題を閉じましょう。 Angular + PDF.js + IE11の実際の使用があるかどうかの確認はありません。使用されている場合は、Angular.jsにパッチを適用することで、Angular側で簡単に修正できます。

ねえ、私はこれが古いトピックであることを知っていますが、私は上記の問題に遭遇しています。

PDF.jsでAngular5を使用しているプロジェクトがあり、IE11をサポートする必要があります。 私はAngularの初心者なので、「Angular.jsにパッチを適用する」方法が正確にはわかりません。この欠陥を回避する方法についてガイダンスを教えてください。 前もって感謝します。

@elliotstonerこの問題は、Angular(2+)ではなくAngularJSの互換性に関するものであり、手動ブートストラップの代わりにng-appを使用する場合にのみ適用されます。 Angular 2+は自動ブートストラップもサポートしていないため、この問題は適用されません。

@mgol Ah

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