Pdf.js: Activer la compatibilité IE 11 d'Angular + pdf.js

On dirait que le blâme passe d'un contrôle de sécurité quelque peu incomplet d'IE11 à la logique angulaire vers le polyfill PDF.js... d'accord. Marquage comme un simple bug pour corriger cette lacune :

1. document.location.origin doit être défini sur la nouvelle URL (document.location.href).origin si la propriété 'origin' est absente
2. HTMLScriptElement.prototype doit avoir les getters d'origine et de protocole avec la même logique que ci-dessus.

@yurydelendik Pour moi, cela est analogue à la situation où quelques API Web ont dû changer de nom parce que MooTools appliquait des polyfills partiels et que le code sur le Web commençait en fonction.

Le polyfilling est risqué, IMO, cela ne devrait être fait qu'avec des polyfills complets et uniquement dans les applications finales, pas dans les bibliothèques. Si les bibliothèques ont besoin d'une API particulière qui n'est pas disponible partout, elles doivent envelopper l'API native dans une fonction utilitaire et utiliser cette fonction ; qui supprime toute la classe de bogues possibles comme celui-ci.

En bref : le code de la bibliothèque ne doit pas modifier les objets qu'il ne possède pas, par exemple les globals natifs du navigateur.

Le polyremplissage est risqué

@mgol oh, je suis d'accord. L'intégralité de l'application de visualisation PDF.js doit résider dans son propre bac à sable (je recommande l'iframe), mais les utilisateurs continuent de l'utiliser dans des applications plus volumineuses. Nous devons donc réagir en conséquence.

le code de la bibliothèque ne doit pas modifier les objets qu'il ne possède pas, par exemple les globals natifs du navigateur.

Prenons un autre exemple, sans tableaux typés et la bibliothèque Promise PDF.js ne serait pas la même. Et en ne modifiant pas les objets globaux, nous rendrions notre code illisible et probablement moins performant pour la majorité des navigateurs modernes.

Prenons un autre exemple, sans tableaux typés et la bibliothèque Promise PDF.js ne serait pas la même. Et en ne modifiant pas les objets globaux, nous rendrions notre code illisible et probablement moins performant pour la majorité des navigateurs modernes.

Pas nécessairement. Vous pouvez conserver votre propre ensemble interne de variables qui masquent les globales. Cela peut ne pas couvrir tous les cas, mais au moins les promesses devraient être bonnes. Quelque chose comme:

var Promise = window.Promise || PROMISE_POLYFILL;

en haut de PDF.js. Dans ce cas, vous ne touchez pas au global et vous pouvez toujours utiliser Promise dans votre code sans aucun changement.

Cela ne devrait pas non plus affecter les performances des navigateurs modernes, car il s'agit d'un simple alias pour eux.

Je comprends que cela peut ne pas être si facile dans tous les cas, cependant (par exemple, si seulement quelques méthodes doivent être polyremplies)

Le code PDF.js se transforme pour utiliser les modules ES6. L'approche ci-dessus peut être problématique pour l'atm, à moins qu'un packager ne fournisse automatiquement un polyfill.

Je ne voudrais pas transformer ce problème en discussion sur la logique angulaire ou l'approche de compatibilité pdf.js, ce sera bien de corriger notre polyfill afin que nous jouions bien avec angulaire. Un PR est le bienvenu :)

Sur la pensée différente, fermons ce problème car cela ne résoudra pas. Il n'y a aucune confirmation qu'il existe des utilisations réelles d'Angular + PDF.js + IE11, s'il y en a, le correctif peut être facilement apporté du côté angulaire en corrigeant Angular.js.

Salut, je sais que c'est un vieux sujet mais je rencontre le problème décrit ci-dessus.

J'ai un projet dans lequel j'utilise Angular 5 avec PDF.js et je dois prendre en charge IE11. Je suis un débutant sur Angular, donc je ne sais pas exactement comment je "corrigerais Angular.js" - pouvez-vous me donner des conseils sur la façon dont je peux contourner ce défaut ? Merci d'avance.

@elliotstoner ce problème concerne la compatibilité AngularJS, pas Angular (2+) et ne s'applique que si vous utilisez ng-app au lieu de l'amorçage manuel. Angular 2+ ne prend même pas en charge l'amorçage automatique, donc ce problème ne s'appliquera pas là-bas.

@mgol Ah ok - Je vais créer un nouveau problème alors, merci.