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

בדף הזה מתועדים הפערים בפלטפורמה שנפתרו במהלך המעבר ל-Manifest V3, ומופיעות תשובות לשאלות נפוצות לגבי המעבר.

פערים בפלטפורמה שנפתרו

הוספנו את היכולות הבאות כדי לטפל בבעיות נפוצות שמונעות העברה:

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

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

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

  • כל האירועים של התוסף וקריאות ה-API יאריכו את משך החיים של Service Worker.
  • במקרים שימוש נבחרים, כמו העברת הודעות מקוריות, עובדי השירות של התוספים יישארו פעילים למשך יותר מ-5 דקות.

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

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

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

פספסנו משהו? נשמח לשמוע ממך.