Pdf.js: Aktifkan kompatibilitas IE 11 dari Angular + pdf.js

Kedengarannya seperti mengalihkan kesalahan dari pemeriksaan keamanan IE11 yang tidak lengkap Logika sudut ke PDF.js polyfill ... baiklah. Menandai sebagai bug sederhana untuk memperbaiki celah ini:

1. document.location.origin harus disetel ke URL baru(document.location.href).origin jika properti 'origin' tidak ada
2. HTMLScriptElement.prototype harus memiliki asal dan pengambil protokol dengan logika yang sama seperti di atas.

@yurydelendik Bagi saya ini analog dengan situasi di mana beberapa Web API harus mengubah nama mereka karena MooTools menerapkan sebagian polyfill dan kode di Web mulai bergantung padanya.

Polyfilling berisiko, IMO itu harus dilakukan hanya dengan polyfill lengkap dan hanya di aplikasi akhir, bukan di perpustakaan. Jika perpustakaan membutuhkan API tertentu yang tidak tersedia di mana-mana, mereka harus membungkus API asli dalam fungsi utilitas dan menggunakan fungsi itu; yang menghapus seluruh kelas kemungkinan bug seperti ini.

Singkatnya: kode perpustakaan tidak boleh memodifikasi objek yang tidak dimilikinya, misalnya global browser asli.

Polyfilling berisiko

@mgol oh, saya setuju. Seluruh aplikasi penampil PDF.js harus berada di kotak pasirnya sendiri (saya sarankan iframe), tetapi orang-orang tetap menggunakannya dalam aplikasi yang lebih besar. Jadi kita harus bereaksi sesuai.

kode perpustakaan tidak boleh memodifikasi objek yang tidak dimilikinya, misalnya global browser asli.

Mari kita ambil contoh lain, tanpa array yang diketik dan pustaka Promise PDF.js tidak akan sama. Dan dengan tidak memodifikasi objek global, kami akan membuat kode kami tidak dapat dibaca dan mungkin kurang berperforma untuk sebagian besar browser modern.

Mari kita ambil contoh lain, tanpa array yang diketik dan perpustakaan Promise PDF.js tidak akan sama. Dan dengan tidak memodifikasi objek global, kami akan membuat kode kami tidak dapat dibaca dan mungkin kurang berperforma untuk sebagian besar browser modern.

Belum tentu. Anda dapat menyimpan set variabel internal Anda sendiri yang membayangi global. Ini mungkin tidak mencakup semua kasus tetapi setidaknya janji harus baik-baik saja. Sesuatu seperti:

var Promise = window.Promise || PROMISE_POLYFILL;

di bagian atas PDF.js. Dalam hal ini Anda tidak menyentuh global dan Anda masih dapat menggunakan Promise dalam kode Anda tanpa perubahan apa pun.

Ini seharusnya tidak memengaruhi kinerja di browser modern karena ini adalah alias sederhana untuk mereka.

Saya mengerti itu mungkin tidak begitu mudah dalam semua kasus, meskipun (misalnya jika hanya beberapa metode yang perlu polyfill)

Kode PDF.js berubah untuk menggunakan modul ES6. Pendekatan di atas bisa menjadi masalah atm, kecuali jika seorang packager akan secara otomatis menyediakan polyfill.

Saya tidak ingin mengubah masalah ini menjadi diskusi tentang logika sudut atau pendekatan kompatibilitas pdf.js, akan menyenangkan untuk memperbaiki polyfill kami sehingga kami akan bermain bagus dengan sudut. PR diterima :)

Pada pemikiran yang berbeda, mari kita tutup masalah ini karena tidak akan diperbaiki. Tidak ada konfirmasi bahwa ada penggunaan dunia nyata Angular+PDF.js+IE11, jika ada, perbaikan dapat dilakukan dengan mudah di sisi sudut dengan menambal Angular.js.

Hai, saya tahu ini adalah topik lama tetapi saya mengalami masalah yang dijelaskan di atas.

Saya memiliki proyek di mana saya menggunakan Angular 5 dengan PDF.js dan saya harus mendukung IE11. Saya seorang pemula di Angular jadi saya tidak yakin bagaimana saya akan "menambal Angular.js" - dapatkah Anda memberi saya beberapa panduan tentang bagaimana saya bisa mengatasi cacat ini? Terima kasih sebelumnya.

@elliotstoner masalah ini adalah tentang kompatibilitas AngularJS, bukan Angular (2+) dan hanya berlaku jika Anda menggunakan ng-app alih-alih bootstrap manual. Angular 2+ bahkan tidak mendukung bootstrap otomatis sehingga masalah ini tidak akan berlaku di sana.

@mgol Ah ok - Saya akan membuat masalah baru, terima kasih.