في كل إصدار من Chrome تقريبًا، نلاحظ عددًا كبيرًا من التحديثات والتحسينات على المنتج وأدائه وإمكانات Web Platform. توضّح هذه المقالة التغييرات في الإصدار 52 من Chrome، وهو إصدار تجريبي اعتبارًا من 9 حزيران (يونيو). تخضع هذه القائمة للتغيير في أي وقت.
إيقاف رموز التشفير المستندة إلى مفتاح التشفير المشترَك بشكل تدريجي
الملخّص: تمّت إزالة التشفير المستنِد إلى مفتاح التشفير المشترَك (DHE) في الإصدار 53 من Chrome لأجهزة الكمبيوتر المكتبي لأنّه غير كافٍ للاستخدام على المدى الطويل. يجب أن تستخدم الخوادم 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 في الإصدار 54 من Chrome.
إزالة سمة النتائج من العنصر <input type=search>
الملخّص: تتم إزالة السمة results لأنّها ليست جزءًا من أي معيار ويتم تنفيذها بشكل غير متّسق في جميع المتصفّحات.
Intent to Remove | Chromestatus Tracker | Chromium Bug
لا يتم تنفيذ قيمة 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.