نلاحظ في كل إصدار من إصدارات Chrome تقريبًا عددًا كبيرًا من التحديثات والتحسينات التي طرأت على المنتج وأدائه وإمكانات "النظام الأساسي للويب". توضّح هذه المقالة التغييرات في الإصدار 52 من Chrome، وهو إصدار تجريبي اعتبارًا من 9 حزيران (يونيو). تخضع هذه القائمة للتغيير في أي وقت.
إيقاف رموز التشفير المستندة إلى مفتاح التشفير المشترَك بشكل تدريجي
النص المختصر (TL;DR): تتم إزالة الرموز المستندة إلى DHE في الإصدار Chrome 53 من أجهزة الكمبيوتر المكتبي لأنّها غير كافية للاستخدام على المدى الطويل. يجب أن تستخدم الخوادم ECDHE، إذا كان متاحًا، أو شفرة RSA عادية إذا لم تكن متاحة.
Intent to Remove | Chromestatus Tracker | Chromium Bug
في العام الماضي، رفعنا في Chrome الحد الأدنى لحجم مجموعة بروتوكول TLS Diffie-Hellman من 512 بت إلى 1024 بت، ولكنّ هذا الحجم غير كافٍ على المدى الطويل. تُظهر المقاييس أنّ حوالي% 95 من عمليات الاتصال التي يستخدمها Chrome عبر بروتوكول مفتاح التشفير من جهة العميل (DHE) تستخدم بروتوكول مفتاح التشفير من جهة العميل بسعة 1024 بت. ويؤدي ذلك إلى جانب طريقة التفاوض على بروتوكول مفتاح التشفير من جهة العميل (DHE) في بروتوكول أمان طبقة النقل (TLS) إلى صعوبة الانتقال إلى أكثر من 1024 بت.
على الرغم من توفّر مسودة مواصفات لحلّ هذه المشكلة، لا تزال هذه المسودة تتطلّب إجراء تغييرات على كلّ من العميل والخادم. وفي الوقت نفسه، يتم تنفيذ برنامج ECDHE ونشره على نطاق واسع. ويجب أن تتم ترقية الخوادم إلى ECDHE في حال توفّرها. بخلاف ذلك، تأكَّد من تفعيل مجموعة رموز تشفير RSA العادية.
تم إيقاف التشفير المستنِد إلى مفتاح التشفير المشترَك (DHE) نهائيًا منذ الإصدار 51 من Chrome. ستتم إزالة هذه الميزة من أجهزة الكمبيوتر المكتبي في الإصدار 53 من Chrome.
تحذير بشأن إيقاف FileError نهائيًا
الملخّص: من المتوقّع أن تتم إزالة واجهة FileError التي تم إيقافها نهائيًا في الإصدار 54 من Chrome. استبدِل الإشارات إلى err.code بـ err.name وerr.message.
Intent to Remove | Chromestatus Tracker | Chromium Bug
لا يحتوي الإصدار الحالي من معيار File API على واجهة FileError، وتم إيقاف استخدامها في وقت ما من عام 2013. في الإصدار 53 من Chrome، ستتم طباعة تحذير الإيقاف هذا على وحدة تحكّم أدوات مطوّري البرامج:
تم إيقاف العنصر FileError نهائيًا وستتم إزالته في الإصدار 54. يُرجى استخدام سمة "الاسم" أو "الرسالة" للخطأ بدلاً من "الرمز".
وهذا له تأثيرات مختلفة في سياقات مختلفة.
- سيصبح سعر اشتراك "
FileReader.error" FileWriter.errorبدلاً من FileError.DOMException - بالنسبة إلى طلبات
FileSystemغير المتزامنة، سيتم تمريرErrorCallbackFileError.ErrorCodeبدلاً منFileError. - بالنسبة إلى مكالمات
FileSystemالمتزامنة، سيتم طرحFileError.ErrorCodeبدلاً منFileError.
لا يؤثّر هذا التغيير إلا في الرمز البرمجي الذي يعتمد على مقارنة رمز مثيل الخطأ (e.code) مباشرةً بقيم التعداد FileError (FileError.NOT_FOUND_ERR وما إلى ذلك). قد يتعذّر استخدام الرمز الذي يختبر مع ثوابت الترميز الثابتة (مثل e.code === 1) عند إبلاغ المستخدم عن أخطاء غير صحيحة.
لحسن الحظ، تتشارك أنواع الأخطاء FileError وDOMError وDOMException جميعًا السمتَين name وmessage اللتين تمنحان أسماء متسقة لحالات الأخطاء (بمعنى آخر، e.name === "NotFoundError"). من المفترض أن يستخدم الرمز البرمجي هاتين السمتَين بدلاً من ذلك، وسيعملان على جميع المتصفّحات وسيستمران في العمل بعد إزالة واجهة FileError نفسها.
من المتوقع أن تتم إزالة FileError من خلال الإصدار Chrome 54.
إزالة سمة النتائج من العنصر <input type=search>
الملخّص: تتم إزالة السمة results لأنّها ليست جزءًا من أي معيار ويتم تنفيذها بشكل غير متّسق في جميع المتصفّحات.
نية الإزالة | أداة تتبُّع Chromestatus | خطأ Chromium
لا يتم تنفيذ قيمة results إلا في webkit، وتختلف طريقة معالجتها اختلافًا كبيرًا في المتصفّحات التي توفّرها. على سبيل المثال، يضيف Chrome رمز المكبِّر إلى مربّع الإدخال، بينما يتحكّم متصفّح Safari للكمبيوتر المكتبي في عدد عمليات البحث السابقة التي يتم عرضها في نافذة منبثقة يتم عرضها من خلال النقر على رمز المكبِّر. وبما أنّ هذا الإجراء ليس جزءًا من أي معيار، سيتم إيقافه نهائيًا.
إذا كنت لا تزال بحاجة إلى تضمين رمز البحث في حقل الإدخال، عليك إضافة بعض الأنماط المخصّصة إلى العنصر. يمكنك إجراء ذلك من خلال تضمين صورة خلفية وتحديد مسافة بادئة على يمين حقل الإدخال.
input[type=search] {
background: url(some-great-icon.png) no-repeat scroll 15px 15px;
padding-left:30px;
}
```
This attribute has been deprecated since Chrome 51.