Pdf.js: 启用 Angular + pdf.js 的 IE 11 兼容性

听起来像是将责任从有些 IE11 不完整的安全检查 Angular 逻辑转移到 PDF.js polyfill ......好吧。 标记为一个简单的错误来修复这个差距：

1. document.location.origin必须设置为新的 URL(document.location.href).origin 如果 'origin' 属性不存在
2. HTMLScriptElement.prototype应具有与上述类似逻辑的 origin 和 protocol getter。

@yurydelendik对我来说，这类似于一些 Web API 不得不更改名称的情况，因为 MooTools 正在应用部分 polyfills 并且 Web 上的代码开始依赖于它。

Polyfilling 是有风险的，IMO 应该只使用完整的 polyfills 并且只在最终应用程序中完成，而不是在库中。 如果库需要一个并非随处可用的特定 API，它们应该将本机 API 包装在一个实用程序函数中并使用该函数； 这消除了像这样的一整类可能的错误。

简而言之：库代码不应修改它不拥有的对象，例如本机浏览器全局变量。

Polyfilling 有风险

@mgol哦，我同意。 整个 PDF.js 查看器应用程序必须驻留在它自己的沙箱中（我推荐 iframe），但人们继续在更大的应用程序中使用它。 所以我们必须做出相应的反应。

库代码不应修改它不拥有的对象，例如本机浏览器全局变量。

让我们再举一个例子，如果没有类型化数组和Promise PDF.js 库就不一样了。 通过不修改全局对象，我们会使我们的代码不可读，并且对于大多数现代浏览器来说性能可能会降低。

让我们再举一个例子，没有类型化数组和 Promise PDF.js 库就不一样了。 通过不修改全局对象，我们会使我们的代码不可读，并且对于大多数现代浏览器来说性能可能会降低。

不必要。 您可以保留自己的内部变量集来隐藏全局变量。 这可能无法涵盖所有​​情况，但至少承诺应该没问题。 就像是：

var Promise = window.Promise || PROMISE_POLYFILL;

在 PDF.js 的顶部。 在这种情况下，您不会触及全局，您仍然可以在代码中使用Promise而无需任何更改。

这不应该影响现代浏览器的性能，因为它是它们的简单别名。

我知道在所有情况下它可能并不那么容易（例如，如果只有少数方法需要填充）

PDF.js 代码正在转换为使用 ES6 模块。 上述方法可能有问题 atm，除非打包程序会自动提供 polyfill。

我不想把这个问题变成关于 angular 逻辑或 pdf.js 兼容性方法的讨论，修复我们的 polyfill 会很好，这样我们就能很好地使用 angular。 欢迎公关:)

换个思路，让我们关闭这个问题，因为它不会解决。 没有确认有 Angular+PDF.js+IE11 实际使用，如果有，可以通过修补 Angular.js 在 angular 方面轻松修复。

嘿，我知道这是一个老话题，但我遇到了上述问题。

我有一个项目，我将 Angular 5 与 PDF.js 一起使用，我需要支持 IE11。 我是 Angular 的新手，所以我不确定我将如何“修补 Angular.js”——你能给我一些关于如何解决这个缺陷的指导吗？ 提前致谢。

@elliotstoner这个问题是关于 AngularJS 兼容性的，而不是 Angular (2+) 并且仅当您使用ng-app而不是手动引导时才适用。 Angular 2+ 甚至不支持自动引导，所以这个问题在那里不适用。

@mgol好的 - 那么我会创建一个新问题，谢谢。