בעיות ידועות במעבר למניפסט מגרסה V3

לאחרונה הודענו על שינויים בלוח הזמנים להוצאה משימוש של Manifest V2. למרות שאנחנו ממשיכים להיות מחויבים בתוקף למניפסט V3, ברור לנו שיש עוד עבודה לעשות מצידנו.

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

צמצום הפער בפלטפורמה

לפני הכרזה על לוח זמנים חדש להוצאה משימוש של Manifest V2, אנחנו מחויבים לסגור את הפערים הבאים:

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

אין כרגע בעיות פתוחות שנחשבות לפער קריטי בפלטפורמה.

הבעיות הבאות טופלו לאחרונה:

  1. תמיכה בטיפול בקבצים ב-ChromeOS כתחליף ל-chrome.fileBrowserHandler [Chrome 120].
  2. תמיכה בסקריפטים של משתמשים: אפשר לרשום סקריפטים של תוכן באמצעות קוד שרירותי באמצעות userScripts API החדש [Chrome 120].
  3. פעולות נוספות של קובץ שירות (service worker) לפעולות מסוימות שנמשכות יותר מחמש דקות.
    • נוסף ב-Chrome 116 עבור permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() ו-management.uninstall().
    • נוסף בגרסה 118 של Chrome ליחידה הארגונית chrome.debugger
  4. הגדלת מספר מערכי הכללים הסטטיים והמופעלים עבור בקשות נטו מוצהרות (DNR). קבוצות הכללים הסטטיות שהופעלו גדלו מ-10 ל-50, וסך הכול קבוצות הכללים הסטטיות מ-50 ל-100 [Chrome 120].
  5. הרחבה של הפונקציונליות של מסמך מחוץ למסך לתמיכה בסיבות נוספות לשימוש במסמך שלא מוצג במסך. הוספנו את GEOLOCATION בגרסה 116 של Chrome.
  6. שיפור התמיכה ב-chrome.tabCapture API [Chrome 116]:
    • תמיכה בהתקשרות אל getMediaStreamId() מ-Service Worker.
    • תמיכה בהשגת MediaStream ממזהה מקור נתונים במסמך שאינו מוצג במסך.
  7. הארכת משך החיים של Service Worker כשיש WebSocket חיבורים פעילים [Chrome 116].

שאלות נפוצות בנושא Manifest V3

ש': האם אנחנו מתכננים לתמוך ב-Service Workers המתמידים?
ת: אחת הסיבות העיקריות למעבר מסקריפטים של רקע ל-Service Workers היא מודל תכנות מבוסס-אירועים יעיל יותר בזיכרון, שמקורו באופי הזמני של קובצי שירות (service worker). לכן אנחנו לא מתכננים לתמוך ב-Service Workers קבועים. עם זאת, כדי לתת מענה לצרכים הספציפיים של מפתחי תוספים, אנחנו ממשיכים לבצע שיפורים רבים ב-Service Workers. הקפידו במיוחד על הדברים הבאים:

  • כל אירועי התוסף והקריאות ל-API יאריכו את משך החיים של קובץ השירות (service worker).
  • תרחישי שימוש נבחרים, כמו העברת הודעות נייטיב, ישאירו את ה-service worker של התוספים במשך יותר מ-5 דקות.

ש': האם יש דרך לגשת ל-DOM ב-Service Workers?
ת: אנחנו נוקטים את הגישה שפלטפורמת האינטרנט נוקטת: לא לכלול גישה ל-DOM ב-Web work (כולל Service works) – כדי לתמוך בתרחישים לדוגמה שמחייבים גישה ל-DOM ברקע מ-Service Workers, הוספנו את האפשרות להעניק גישה לעבודה ברקע במסמכים מחוץ למסך לטווח קצר שמספקים גישה מלאה ל-DOM.

שאלה: האם תהיה דרך לתמוך בקוד מרחוק במניפסט V3?
ת: כדי שתוספי Chrome יהיו מאובטחים יותר, נמשיך לאסור על הפעלת קוד שרירותי שמתארח מרחוק בתוספי Chrome. עם זאת, זה לא אומר שאנחנו אוסרים על ביצוע כל הסוגים של קוד דינמי. אנחנו עדיין תומכים באפשרויות שונות להפעלה דינמית של קוד בתוספים ל-Chrome:

ש: התוסף My Manifest V2 מסתמך על webRequestBlock, שלא נתמך במניפסט V3. איך אפשר להמשיך לספק את אותה פונקציונליות במניפסט מגרסה V3?
תשובה: אנחנו בטוחים שניתן לפתור את רוב התרחישים לדוגמה לחסימת בקשות באמצעות declarativeNetRequest API החדש, שיש לו יתרון נוסף: הימנעות מתקורת הביצועים של תקשורת בין תהליכים, הפעלת קוד בכל בקשה או דרישה לתהליך הארכה פעיל בזמן שליחת הבקשה. עם זאת, בתרחישים מורכבים לדוגמה ארגוניים (או חינוכיים), עדיין יש תמיכה בחסימה דינמית של בקשות.

פספסנו משהו? חשוב לנו לדעת.