Pdf.js: تفعيل توافق IE 11 مع Angular + pdf.js

تم إنشاؤها على ٢٤ مارس ٢٠١٧ · 10تعليقات · مصدر: mozilla/pdf.js

إعدادات:

متصفح الويب ونسخته: IE 11
نظام التشغيل ونسخته: أي
إصدار PDF.js: 1.4.0
إصدار AngularJs: 1.5.11

خطوات إعادة إظهار المشكلة:

استخدم AngularJS 1.5.11 مع التمهيد التلقائي
قم بتضمين الإصدار 1.4.0 من PDF.js قبل علامات البرنامج النصي لـ Angular

ما هو السلوك المتوقع؟ (إضافة لقطة شاشة)

يعمل Angular بشكل مثالي مع PDF.js
يقوم PDF.js بلف واجهة برمجة التطبيقات المفقودة في الوظائف التي ستستخدم النسخة المتلألئة إذا كانت النسخة الأصلية غير متوفرة.

ماذا حصل؟ (إضافة لقطة شاشة)

انظر https://github.com/angular/angular.js/issues/15772
يعرّف pdf.js حاليًا document.currentScript وليس link.origin ولا link.protocol. إذا بدأ الزاوي ، فإنه يتحقق مما إذا كان مسموحًا به للتمهيد تلقائيًا ، فإنه يتحقق من CurrentScript ويفترض أن هذا سيكون كافيًا لتصفية IE ، مما يعني أنه إذا لم يتم تعريف CurrentScript ، فيمكننا تلقائيًا تمهيد. لن يعمل هذا الفحص مع pdf.js.

لا ينبغي للمكتبات تعديل خصائص الكائنات التي لا تمتلكها لأنها تسبب مشكلات مثل هذه. إذا احتاجوا إلى واجهة برمجة تطبيقات معينة مفقودة في بعض البيئات المدعومة ، فيمكنهم التفاف استخدامها في وظيفة ستستخدم الإصدار المتلألئ إذا لم تكن النسخة الأصلية متوفرة.

ارتباط إلى عارض (إذا تمت استضافته على موقع بخلاف mozilla.github.io/pdf.js أو كملحق Firefox / Chrome):
http://plnkr.co/edit/YFCQM2Px0QU0KnGzsAlM؟p=preview

1-other

مصدر

Wolfke85

👍1

ال 10 كومينتر

يبدو مثل تحويل اللوم من فحص أمان IE11 غير مكتمل إلى حد ما المنطق الزاوي إلى PDF.js polyfill ... حسنًا. وضع علامة على أنها خطأ بسيط لإصلاح هذه الفجوة:

يجب تعيين document.location.origin إلى عنوان URL جديد (document.location.href) .origin إذا كانت خاصية "origin" غير موجودة
HTMLScriptElement.prototype يجب أن يكون له أصل والبروتوكول بمنطق مماثل كما هو مذكور أعلاه.

yurydelendik في ٢٤ مارس ٢٠١٧

yurydelendik بالنسبة لي ، هذا مشابه

يعد Polyfilling محفوفًا بالمخاطر ، ويجب أن يتم ذلك باستخدام IMO فقط مع polyfill الكامل وفقط في التطبيقات النهائية ، وليس في المكتبات. إذا احتاجت المكتبات إلى واجهة برمجة تطبيقات معينة غير متوفرة في كل مكان ، فيجب عليها التفاف واجهة برمجة التطبيقات الأصلية في وظيفة الأداة المساعدة واستخدام هذه الوظيفة ؛ يزيل فئة كاملة من الأخطاء المحتملة مثل هذه.

باختصار: رمز المكتبة لا ينبغي أن يعدل الكائنات التي لا تمتلكها ، على سبيل المثال جلوبال المستعرض الأصلي.

mgol في ٢٤ مارس ٢٠١٧

Polyfilling محفوف بالمخاطر

mgol أوه ، أوافق. يجب أن يكون تطبيق عارض PDF.js بأكمله موجودًا في وضع الحماية الخاص به (أوصي باستخدام iframe) ، ولكن يستمر الأشخاص في استخدامه داخل التطبيقات الأكبر حجمًا. لذلك علينا أن نتصرف وفقًا لذلك.

yurydelendik في ٢٤ مارس ٢٠١٧

يجب ألا يعدل كود المكتبة الكائنات التي لا يمتلكها ، على سبيل المثال globals المستعرض الأصلي.

لنأخذ مثالًا آخر ، بدون المصفوفات المكتوبة ولن تكون مكتبة PDF.js Promise هي نفسها. ومن خلال عدم تعديل الكائنات العالمية ، سنجعل الكود الخاص بنا غير قابل للقراءة وربما أقل أداءً لغالبية المتصفحات الحديثة.

yurydelendik في ٢٤ مارس ٢٠١٧

لنأخذ مثالًا آخر ، بدون المصفوفات المكتوبة ولن تكون مكتبة Promise PDF.js هي نفسها. ومن خلال عدم تعديل الكائنات العالمية ، سنجعل الكود الخاص بنا غير قابل للقراءة وربما أقل أداءً لغالبية المتصفحات الحديثة.

ليس بالضرورة. يمكنك الاحتفاظ بمجموعتك الداخلية من المتغيرات التي تظلل الكرات الأرضية. قد لا يغطي هذا جميع الحالات ولكن على الأقل يجب أن تكون الوعود على ما يرام. شيء مثل:

var Promise = window.Promise || PROMISE_POLYFILL;

أعلى ملف PDF.js. في هذه الحالة ، لا تلمس العام ولا يزال بإمكانك استخدام Promise في الكود الخاص بك دون أي تغييرات.

لا ينبغي أن يؤثر هذا على الأداء في المتصفحات الحديثة إما لأنه اسم مستعار بسيط لها.

أفهم أنه قد لا يكون الأمر بهذه السهولة في جميع الحالات ، على الرغم من (على سبيل المثال ، إذا كانت هناك حاجة إلى عدة طرق فقط)

mgol في ٢٤ مارس ٢٠١٧

يتم تحويل كود PDF.js لاستخدام وحدات ES6. يمكن أن يمثل النهج أعلاه مشكلة في أجهزة الصراف الآلي ، ما لم توفر أداة التغليف تلقائيًا polyfill.

لا أرغب في تحويل هذه المشكلة إلى مناقشة حول المنطق الزاوي أو نهج توافق pdf.js ، سيكون من الجيد إصلاح polyfill الخاص بنا حتى نلعب بشكل لطيف مع الزاوية. العلاقات العامة هي موضع ترحيب :)

yurydelendik في ٢٤ مارس ٢٠١٧

على فكرة مختلفة ، دعنا نغلق هذه المشكلة لأن لن يتم حلها. لا يوجد تأكيد على استخدام Angular + PDF.js + IE11 في العالم الحقيقي ، إذا كان هناك استخدامات ، فيمكن إجراء الإصلاح بسهولة على الجانب الزاوي من خلال تصحيح Angular.js.

yurydelendik في ١٤ يونيو ٢٠١٧

👎9

مرحبًا ، أعلم أن هذا موضوع قديم ولكني أواجه المشكلة الموضحة أعلاه.

لدي مشروع أستخدم فيه Angular 5 مع PDF.js وأنا مطالب بدعم IE11. أنا مبتدئ في Angular لذا لست متأكدًا تمامًا من كيفية "تصحيح Angular.js" - هل يمكنك إعطائي بعض الإرشادات حول كيفية التغلب على هذا العيب؟ شكرا لك مقدما.