Pdf.js: Включить совместимость с IE 11 для Angular + pdf.js

Похоже, перекладывание вины с некоторой неполной проверки безопасности IE11 на логику Angular на полифил PDF.js ... хорошо. Отметим как простую ошибку, чтобы исправить этот пробел:

1. document.location.origin должен быть установлен на новый URL (document.location.href) .origin, если свойство origin отсутствует
2. HTMLScriptElement.prototype должен иметь источники происхождения и протокола с той же логикой, что и выше.

@yurydelendik Для меня это аналогично ситуации, когда нескольким веб-API пришлось изменить свои имена, потому что MooTools применял частичные полифилы, и код в Интернете запускался в зависимости от этого.

Полифиллинг - это рискованно, ИМО, это должно выполняться только с полными полифилами и только в конечных приложениях, а не в библиотеках. Если библиотекам нужен конкретный API, который доступен не везде, они должны заключить собственный API в служебную функцию и использовать эту функцию; который устраняет целый класс возможных ошибок, подобных этой.

Вкратце: код библиотеки не должен изменять объекты, которыми он не владеет, например глобальные объекты собственного браузера.

Полифиллинг - это рискованно

@mgol ой согласен. Все приложение просмотра PDF.js должно находиться в отдельной песочнице (я рекомендую iframe), но люди продолжают использовать его в более крупных приложениях. Поэтому мы должны соответствующим образом реагировать.

код библиотеки не должен изменять объекты, которыми он не владеет, например глобальные объекты собственного браузера.

Возьмем другой пример, без типизированных массивов и библиотеки Promise PDF.js не было бы таким же. И, не изменяя глобальные объекты, мы сделаем наш код нечитаемым и, вероятно, менее производительным для большинства современных браузеров.

Возьмем другой пример, без типизированных массивов и библиотеки Promise PDF.js не было бы того же. И, не изменяя глобальные объекты, мы сделаем наш код нечитаемым и, вероятно, менее производительным для большинства современных браузеров.

Не обязательно. Вы можете сохранить свой собственный внутренний набор переменных, которые затеняют глобальные переменные. Это может не охватывать все случаи, но, по крайней мере, обещания должны подойти. Что-то вроде:

var Promise = window.Promise || PROMISE_POLYFILL;

вверху PDF.js. В этом случае вы не касаетесь глобального, и вы все равно можете использовать Promise в своем коде без каких-либо изменений.

Это также не должно влиять на производительность современных браузеров, поскольку это простой псевдоним для них.

Я понимаю, что во всех случаях это может быть не так просто (например, если нужно полифилить только несколько методов)

Код PDF.js трансформируется для использования модулей ES6. Вышеупомянутый подход может быть проблематичным, если только упаковщик автоматически не предоставит полифил.

Я бы не хотел превращать этот вопрос в обсуждение логики angular или подхода совместимости с pdf.js, было бы неплохо исправить наш полифилл, чтобы мы хорошо играли с angular. Приветствуется пиар :)

С другой стороны, давайте закроем эту проблему, так как не исправим. Нет подтверждения того, что Angular + PDF.js + IE11 используется в реальном мире, если есть, исправление можно легко сделать на стороне angular, исправив Angular.js.

Привет, я знаю, что это старая тема, но я столкнулся с проблемой, описанной выше.

У меня есть проект, в котором я использую Angular 5 с PDF.js, и мне нужно поддерживать IE11. Я новичок в Angular, поэтому я не совсем уверен, как бы «исправить Angular.js» - не могли бы вы дать мне какие-нибудь рекомендации относительно того, как я могу обойти этот дефект? Заранее спасибо.

@elliotstoner эта проблема касается совместимости с AngularJS, а не с Angular (2+), и применяется только в том случае, если вы используете ng-app вместо ручной начальной загрузки. Angular 2+ даже не поддерживает автоматическую загрузку, поэтому эта проблема там не применяется.

@mgol А, ладно, тогда я создам новый выпуск, спасибо.