في كل إصدار من Chrome تقريبًا، نلاحظ عددًا كبيرًا من التحديثات والتحسينات على المنتج وأدائه وإمكانات Web Platform. توضّح هذه المقالة الميزات التي سيتم إيقافها نهائيًا أو إزالتها في الإصدار 60 من Chrome، الذي أصبح متاحًا في إصدار تجريبي اعتبارًا من 8 حزيران (يونيو). تخضع هذه القائمة للتغيير في أي وقت.
الأمان
يتطلب الإجراء crypto.subtle الآن مصدرًا آمنًا.
إنّ واجهة برمجة التطبيقات Web Crypto API
التي كانت متاحة منذ الإصدار 37 من Chrome كانت تعمل دائمًا مع مصادر
غير آمنة. بسبب سياسة Chrome المتّبعة منذ فترة طويلة والمتعلّقة بمنح الأولوية للمصادر الآمنة للاستفادة من الميزات القوية،
لا يظهر crypto.subtle فقط على المصادر الآمنة.
النية في الإزالة | خطأ في Chromium
إزالة عمليات التنقّل التي يبدأها المحتوى في أعلى الإطار إلى عناوين URL للبيانات
ونظرًا لعدم معرفة مستخدمي المتصفّح غير التقنيين بأسلوب data:، نرى
بشكل متزايد استخدام هذا الأسلوب في هجمات التصيّد والتزوير. لمنع حدوث ذلك، نحظر على صفحات الويب تحميل عناوين URL الخاصة بـ data:
في الإطار العلوي. ينطبق ذلك على علامات <a> وwindow.open
window.location والآليات المشابهة. سيظلّ مخطّط data: صالحًا
للموارد التي تحمّلها صفحة.
تم إيقاف هذه الميزة نهائيًا في الإصدار 58 من Chrome وتمّت إزالتها الآن.
Intent to Remove | Chromestatus Tracker | Chromium Bug
إيقاف navigator.sendBeacon() مؤقتًا لبعض العناصر
أصبحت الدالة navigator.sendBeacon() متاحة
منذ الإصدار 39 من Chrome.
وفقًا للتنفيذ الأصلي، يمكن أن تحتوي الوسيطة data للدالة على أي
بيانات ثنائية كبيرة عشوائية لا يكون نوعها مدرَجًا في القائمة الآمنة لبروتوكول CORS. نعتقد أنّ هذا الخطر يمثّل تهديدًا محتمَلاً للأمان، على الرغم من أنّه لم يحاول أحد استغلاله بعد. بسبب عدم توفّر حلّ فوري معقول، لن يعود بإمكانك مؤقتًا استخدام sendBeacon() مع ملفات البيانات التي لا تندرج ضمن القائمة الآمنة لبروتوكول CORS.
على الرغم من أنّه تم تنفيذ هذا التغيير في الإصدار 60 من Chrome، تم دمجه مجددًا في الإصدار 59.
CSS
جعل أسلوب الربط للعنصر المتسلسل الذي يخترق الظلّ يتصرف مثل أسلوب الربط للعنصر المتسلسل
.كان المقصود من تركيبة العنصر المتسلسل الذي يخترق الظل (>>>)، وهو جزء من
وحدة تحديد النطاق في CSS، المستوى 1
، مطابقة العناصر الثانوية لعنصر سلف معيّن
حتى عندما تظهر داخل شجرة ظل. وكان لهذا الإجراء بعض القيود.
أولاً، وفقًا للمواصفات، كان
يمكن استخدامه فقط في طلبات JavaScript، مثل querySelector()، ولم يكن
يعمل في أوراق الأنماط. الأهم من ذلك، لم يتمكّن مورّدو المتصفّحات من جعله يعمل على مستوى أكثر من مستوى واحد من Shadow DOM.
نتيجةً لذلك، تمت إزالة عنصر الربط للعنصر اللاحق من المواصفات ذات الصلة، بما في ذلك الإصدار 1 من Shadow DOM. بدلاً من إيقاف صفحات الويب عن العمل عن طريق إزالة هذا العنصر المحدد من Chromium، اخترنا بدلاً من ذلك إنشاء اسم بديل لدمج العنصر اللاحق الذي يخترق الظلّ مع دمج العنصر اللاحق. وتمإيقاف السلوك الأصلي نهائيًا في الإصدار 45 من Chrome. تم تنفيذ السلوك الجديد في الإصدار 61 من Chrome.
Intent to Remove | Chromestatus Tracker | Chromium Bug
JavaScript
إيقاف RTCPeerConnection.getStreamById() نهائيًا وإزالته
قبل عامَين تقريبًا، تمت إزالة getStreamById() من مواصفات WebRTC. وقد أزالت معظم المتصفّحات الأخرى
هذا الإصدار من عمليات التنفيذ. على الرغم من أنّه يُعتقد أنّ هذه الدالة
لا يتم استخدامها كثيرًا، يُعتقد أيضًا أنّ هناك بعض المخاطر البسيطة
في إمكانية التشغيل التفاعلي مع متصفّح Edge والمتصفّحات المستندة إلى WebKit باستثناء Safari
حيث لا تزال دالة getStreamById() متاحة. يمكن للمطوّرين الذين يحتاجون إلى تنفيذ بديل للعميل العثور على نموذج رمز في قسم "النية في الإزالة" أدناه.
تمّت إزالة هذه الميزة في الإصدار 62 من Chrome.
Intent to Remove | Chromestatus Tracker | Chromium Bug
إيقاف SVGPathElement.getPathSegAtLength نهائيًا
قبل أكثر من عامَين، تم إزالة getPathSegAtLength() من مواصفات SVG.
ونظرًا لعدد قليل من النتائج التي تشير إلى هذه الطريقة في httparchive، سيتم
إيقافها نهائيًا في الإصدار 60 من Chrome. من المتوقّع أن تتم إزالة هذه الميزة في الإصدار 62 من Chrome، والذي
سيتم طرحه في وقت ما في أوائل أو منتصف تشرين الأول (أكتوبر).
القرار بإيقاف الميزة نهائيًا | تتبُّع حالة Chrome | خطأ في Chromium
نقل getContextAttributes() إلى ما بعد العلامة
أصبحت الدالة getContextAttributes() متاحة في
CanvasRenderingContext2D
منذ عام 2013. ومع ذلك، لم تكن الميزة جزءًا من أي معيار ولم تصبح
جزءًا من أي معيار منذ ذلك الوقت. كان من المفترض أن يتم تنفيذه بعد علامة سطر الأوامر
--enable-experimental-canvas-features، ولكن تم تنفيذه
بغير قصد. تم تصحيح هذا الخطأ في الإصدار 60 من Chrome. يُعتقد أنّ هذا
التغيير آمن، لأنّه لا تتوفّر بيانات تُظهر أنّ أيّ مستخدم يعتمد هذه الطريقة.
أزِل Headers.prototype.getAll().
تتم إزالة الدالة Headers.prototype.getAll() وفقًا لأحدث
إصدار من مواصفات Fetch.
Intent to Remove | Chromestatus Tracker | Chromium Bug
أزِل indexedDB.webkitGetDatabaseNames().
أضفنا هذه الميزة عندما كان Indexed DB جديدًا نسبيًا في Chrome وكانت البادئة رائجة. تعرض واجهة برمجة التطبيقات بشكل غير متزامن قائمة بأسماء قاعدة بيانات الحالية في مصدر، ما بدا منطقيًا بما يكفي.
للأسف، يتضمّن التصميم عيوبًا، إذ قد تصبح النتائج قديمة بعد ثواني من عرضها، لذا لا يمكن استخدامها إلا للتسجيل، وليس لتطبيق منطق جاد. تتتبّع مشكلة github/ترتبط بمناقشة سابقة حول البدائل، ما يتطلّب نهجًا مختلفًا. على الرغم من أنّ المطوّرين أبدوا اهتمامًا متقطعًا بهذه المشكلة، إلا أنّهم توصّلوا إلى حلّ لها بسبب عدم إحراز أي تقدم في حلّها على مستوى جميع المتصفّحات.
على المطوّرين الذين يحتاجون إلى هذه الوظيفة تطوير حلّهم الخاص. على سبيل المثال، تستخدِم المكتبات مثل Dexie.js جدولاً شاملاً وهو نفسه قاعدة بيانات أخرى لتتبُّع أسماء قواعد البيانات.
تم إيقاف هذه الميزة نهائيًا في الإصدار 58 من Chrome وتمّت إزالتها الآن.
النية في الإزالة | Chromestatus Tracker | خطأ في Chromium
أزِل WEBKIT_KEYFRAMES_RULE وWEBKIT_KEYFRAME_RULE.
تتم إزالة الثابتَين غير العاديَين WEBKIT_KEYFRAMES_RULE وWEBKIT_KEYFRAME_RULE
من
قاعدة CSS.
على المطوّرين استخدام KEYFRAMES_RULE وKEYFRAME_RULE بدلاً من ذلك.
النية في الإزالة | Chromestatus Tracker | خطأ في Chromium
واجهة المستخدم
طلب إيماءة من المستخدم لمربّعات حوار beforeunload
اعتبارًا من الإصدار 60 من Chrome، لن يظهر مربّع الحوار beforeunload إلا إذا تلقّى الإطار الذي يحاول عرضه إيماءة من المستخدم أو تفاعلًا منه (أو إذا تلقّى أي إطار مضمّن هذه الإيماءة). للتوضيح، هذا ليس
تغييرًا في إرسال حدث beforeunload. هذا مجرد تغيير في
ما إذا كان سيتم عرض مربّع الحوار.
مربّع الحوار beforeunload هو مربّع حوار مشروط للتطبيق. وبالتالي، فإنّها تُعدّ بطبيعتها
غير ودية للمستخدم، ما يعني أنّها تستجيب لتنقّل المستخدم من خلال التشكيك في
قراره. هناك استخدامات إيجابية لهذه الميزة. على سبيل المثال، يتم استخدامه غالبًا
لتحذير المستخدمين عندما سيفقدون البيانات أثناء التنقّل.
على الرغم من أنّه تمت منذ فترة إزالة إمكانية أن تقدّم الصفحة نصًا لمربّع حوار beforeunload، لا تزال مربّعات حوار beforeunload وسيلة إساءة استخدام. ويُعدّ beforeunload مربّع الحوار أحد مكوّنات المواقع الإلكترونية المخادعة، حيث يشكّل تشغيل الصوت تلقائيًا والنص المهدد سياقًا تصبح فيه رسالة "هل أنت متأكّد من أنّك تريد مغادرة هذه الصفحة؟" التي يوفّرها Chromium مصدر قلق.
نريد أن نضع حدًا للاستخدامات غير الملائمة، ونسمح فقط باستخدامات beforeunload
الحوار الجيدة. إنّ الاستخدامات الجيدة لمربّع الحوار هي تلك التي يكون فيها للمستخدم حالة قد يتم
فقدانها. إذا لم يتفاعل المستخدم مع الصفحة مطلقًا، لا يمكن أن يكون لديه أي حالة قد يتم فقدانها، وبالتالي لا نخاطر بفقدان بيانات المستخدم من خلال كتم مربّع الحوار في هذه الحالة.