הוצאה משימוש והסרות של ממשקי API ב-Chrome 50

כמעט בכל גרסה של Chrome אנחנו מוסיפים מספר רב של עדכונים ושיפורים למוצר, לביצועים שלו וגם ליכולות של פלטפורמת האינטרנט.

ב-Chrome 50 (תאריך בטא משוער: 10 עד 17 במרץ) יש מספר שינויים ב-Chrome. הרשימה הזו עשויה להשתנות בכל שלב.

מטמון האפליקציה הוצא משימוש בהקשרים לא מאובטחים

אמ;לק: כדי לפגוע בכתיבת סקריפטים באתרים שונים, אנחנו מוציאים משימוש את AppCache במקורות לא מאובטחים. אנחנו צופים שב-Chrome 52 הוא יפעל רק במקורות שמציגים תוכן באמצעות HTTPS.

Intent להסרה | מעקב אחר Chromestatus | באג ב-Chromium

מטמון האפליקציה מאפשר גישה אופליין וגישה קבועה למקור – הסלמת הרשאות (privilege escalation) לטיפול ברמה גבוהה יותר של התקפת סקריפטים חוצי-אתרים. כחלק ממאמץ גדול יותר להסרת תכונות מתקדמות במקורות לא מאובטחים.

כדי להסיר את וקטור ההתקפה הזה, Chrome מאפשר אותו רק דרך HTTPS. אנחנו מוציאים משימוש את התמיכה ב-HTTP ב-Chrome 50, וצפויים להסיר אותה לחלוטין ב-Chrome 52.

השדה Document.defaultCharset הוסר

אמ;לק: document.defaultCharset הוסר כדי לשפר את התאימות למפרט.

כוונה להסרה | מעקב אחר סטטוס הבעיות ב-Chrome | דיווח על בעיה ב-CRBug

המאפיין document.defaultCharset, שהוצא משימוש ב-Chrome 49, הוא מאפיין לקריאה בלבד שמחזיר את קידוד התווים שמוגדר כברירת מחדל במערכת של המשתמש על סמך ההגדרות האזוריות שלו. לא נמצא יתרון בשמירה על הערך הזה בגלל האופן שבו הדפדפנים משתמשים במידע על קידוד התווים בתגובה ל-HTTP או במטא תג שמוטמע בדף.

במקום זאת, צריך להשתמש ב-document.characterSet כדי לקבל את הערך הראשון שצוין בכותרת ה-HTTP. אם המאפיין הזה לא קיים, תקבלו את הערך שצוין במאפיין charset של הרכיב <meta> (לדוגמה, <meta charset="utf-8">). אם אף אחד מהרכיבים האלה לא זמין, document.characterSet תהיה הגדרת המערכת של המשתמש.

תוכלו לקרוא עוד דיון על הסיבות לכך שלא לפרט זאת בבעיית github הזו

TL;DR: מסירים את התמיכה בערך subresource של המאפיין rel ב-HTMLLinkElement.

כוונה להסרה | מעקב אחר סטטוס Chrome | באג ב-Chromium

מטרת המאפיין subresource ב-<link> הייתה לבצע טעינה מראש של משאב במהלך זמן ההשבתה של הדפדפן. אחרי שהדפדפן הוריד דף, הוא יכול להוריד מראש משאבים כמו דפים אחרים, כדי שכשהמשתמשים יבקשו אותם, הם יוכלו פשוט לאחזר אותם מהמטמון של הדפדפן.

במאפיין subresource היו כמה בעיות. קודם כול, היא אף פעם לא פעלה כמצופה. המשאבים שצוינו הורדו בעדיפות נמוכה. המאפיין לא יושם אף פעם בדפדפן אחר מלבד Chrome. בהטמעה של Chrome הייתה באג שגרם להורדה של משאבים פעמיים.

למפתחים שרוצים לשפר את חוויית המשתמש באמצעות טעינת תוכן מראש יש כמה אפשרויות, והאפשרות הכי גמישה היא ליצור עובד שירות כדי לנצל את היתרונות של אחסון מראש ו-Caches API. פתרונות נוספים כוללים ערכים אחרים למאפיין rel, כולל preconnect,‏ prefetch,‏ preload,‏ prerender. חלק מהאפשרויות האלה הן ניסיוניות וייתכן שהן לא נתמכות באופן נרחב.

הסרת האפשרות להשתמש בגרסת TLS קודמת לא מאובטחת

TL;DR: הסרת מנגנון לאלץ שרתי TLS להחזיר נתונים באמצעות גרסאות פחות מאובטחות או לא מאובטחות של TLS.

כוונה להסרה | מעקב אחר סטטוס Chrome | באג ב-Chromium

אבטחת שכבת התעבורה (TLS) תומכת במנגנון לניהול משא ומתן על גרסאות, שמאפשר להציג גרסאות TLS חדשות בלי לשבור את התאימות. חלק מהשרתים הטמיעו את האפשרות הזו כך שהדפדפנים נדרשו להשתמש בנקודות קצה לא מאובטחות כחלופה. לכן, תוקפים יכולים לאלץ כל אתר, לא רק את אלה שהוגדרו באופן שגוי, לנהל משא ומתן על גרסאות חלשות יותר של TLS.

האתרים שמושפעים לא יוכלו להתחבר אל ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. האדמינים צריכים לוודא שתוכנת השרת שלהם מעודכנת. אם הבעיה לא נפתרה, פנו לספק תוכנת השרת כדי לבדוק אם יש פתרון.

הסרת KeyboardEvent.prototype.keyLocation

TL;DR: מסירים כינוי לא נדרש למאפיין Keyboard.prototype.location.

Intent להסרה | מעקב אחר Chromestatus | באג ב-Chromium

המאפיין הזה הוא פשוט כינוי למאפיין Keyboard.prototype.location, שמאפשר להבדיל בין מפתחות שנמצאים במספר מקומות במקלדת. לדוגמה, שני המאפיינים מאפשרים למפתחים להבחין בין שני מקשי Enter במקלדת מורחבת.

רכיבי handler של שגיאות והצלחה שנדרשים בשיטות RTCPeerConnection

TL;DR: השיטות createOffer() ו-createAnswer() של WebRTC‏ RTCPeerConnection מחייבות עכשיו טיפול בשגיאות וגם טיפול בהצלחה. בעבר אפשר היה להפעיל את השיטות האלה רק עם טיפול הצלחה. השימוש הזה הוצא משימוש.

Intent להסרה | מעקב אחר Chromestatus | באג ב-Chromium

ב-Chrome 49 הוספנו אזהרה אם קוראים ל-setLocalDescription() או ל-setRemoteDescription() בלי לספק מנהל שגיאות. הארגומנט של מנהל השגיאות הוא חובה החל מגרסה 50 של Chrome.

זהו חלק מההכנות להוספת הבטחות לשיטות האלה, כפי שנדרש במפרט WebRTC.

הנה דוגמה מהדגמה של RTCPeerConnection ב-WebRTC‏ (main.js, שורה 126):

    function onCreateOfferSuccess(desc) {
      pc1.setLocalDescription(desc, function() {
         onSetLocalSuccess(pc1);
      }, onSetSessionDescriptionError);
      pc2.setRemoteDescription(desc, function() {
        onSetRemoteSuccess(pc2);
      }, onSetSessionDescriptionError);
      pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
    }

שימו לב של-setLocalDescription() וגם ל-setRemoteDescription() יש בורר שגיאות. בדפדפנים ישנים יותר שמצפים רק למטפל הצלחה, הארגומנט של מטפל השגיאות פשוט יתעלם אם הוא קיים. קריאה לקוד הזה בדפדפן ישן לא תגרום לחריגה.

באופן כללי, לאפליקציות WebRTC בסביבת הייצור מומלץ להשתמש ב-adapter.js, שכבת תמיכה שמנוהלת על ידי פרויקט WebRTC, כדי להגן על האפליקציות מפני שינויים במפרט ומפני הבדלים בתחילית.

אין יותר תמיכה ב-XMLHttpRequestProgressEvent

קיצור: הממשק XMLHttpRequestProgressEvent יוסר, יחד עם המאפיינים position ו-totalSize.

כוונה להסרה | מעקב אחר סטטוס Chrome | באג ב-Chromium

האירוע הזה היה קיים כדי לתמוך במאפייני התאימות של Gecko‏ position ו-totalSize. התמיכה בכל השלושה הופסקה בגרסה 22 של Mozilla, והפונקציונליות הוחלפה מזמן על ידי ProgressEvent.

     var progressBar = document.getElementById("p"),
          client = new XMLHttpRequest()
      client.open("GET", "magical-unicorns")
      client.onprogress = function(pe) {
        if(pe.lengthComputable) {
          progressBar.max = pe.total
          progressBar.value = pe.loaded
        }
      }

הסרה של תוספים של מדיה מוצפנת עם קידומת

TL;DR: הוסרו תוספים של מדיה מוצפנת עם קידומת, והם הוחלפו בתוספים ללא קידומת שמבוססים על מפרט.

כוונה להסרה | מעקב אחר סטטוס Chrome | באג ב-Chromium

ב-Chrome 42 השקנו גרסה מבוססת-מפרט של תוספים של מדיה מוצפנת, ללא קידומת. ה-API הזה משמש לחיפוש מערכות של ניהול זכויות דיגיטלי (DRM), לבחירה ולאינטראקציה איתן, לשימוש עם HTMLMediaElement.

זה היה לפני כמעט שנה. מכיוון שלגרסה ללא הקידומת יש יותר יכולות מאשר לגרסה עם הקידומת, הגיע הזמן להסיר את הגרסה עם הקידומת של ה-API.

הסרת התמיכה במאפייני SVGElement.offset

TL;DR: מאפייני ההזזה של SVGElement הוסרו לטובת המאפיינים הנתמכים יותר ב-HTMLElement.

כוונה להסרה | מעקב אחר סטטוס Chrome | באג ב-Chromium

נכסי שינוי אופקי נתמכים כבר זמן רב גם ב-HTMLElement וגם ב-SVGElement. עם זאת, Gecko ו-Edge תומכים בהם רק ב-HTMLElement. כדי לשפר את העקביות בין הדפדפנים, הנכסים האלה הוצאו משימוש בגרסה 48 של Chrome והם יוסרו עכשיו.

למרות שמאפיינים מקבילים הם חלק מ-HTMLElement, מפתחים שמחפשים חלופה יכולים להשתמש גם ב-getBoundingClientRect()