מעבר למרחב שמות של דפדפן

החל מ-Chrome 148, כל ממשקי ה-API של תוספי Chrome זמינים במרחב השמות browser בנוסף למרחב השמות הקיים chrome. לדוגמה, browser.tabs.create({}) ו-chrome.tabs.create({}) שקולים.

מרחב השמות זמין בכל מקום שבו אפשר לקרוא לממשקי API של תוספים, כולל סקריפטים של תוכן, service workers ומסמכים מחוץ למסך. הוא מצביע על אותם אובייקטים של API כמו chrome, ולכן chrome.tabs === browser.tabs.

מרחב השמות browser הוא תוצאה של עבודה ב-WebExtensions Community Group (WECG), קבוצת קהילה של W3C שבה ספקי דפדפנים משתפים פעולה בנושא תקנים משותפים של תוספים. מרחב השמות chrome לא ייעלם, ושני מרחבי השמות ימשיכו לפעול.

החלטה אם לאמץ את מרחב השמות של הדפדפן

אם אתם משתמשים ב-webextension-polyfill, כדאי לעבור אל הערה למשתמשים ב-polyfill לפני שתבצעו שינויים אחרים – התשובה שונה עבורכם.

אם אתם יוצרים תוסף חדש, צריך להגדיר את minimum_chrome_version ל-"148" ולהשתמש ב-browser ללא תנאי. אתם יכולים להפסיק לקרוא כאן. החלק הבא מיועד לתוספים קיימים שרוצים לדעת איך לעבור לשימוש ב-Manifest V3.

איך בודקים באיזו גרסה של Chrome המשתמשים משתמשים

אם יש לכם תוסף קיים, כדאי לבדוק איזו גרסה של Chrome מותקנת אצל המשתמשים לפני שאתם עוברים לגרסה חדשה. ‫Chrome מתעדכן אוטומטית, אבל חלק מהמשתמשים משביתים את העדכונים, ואחרים משתמשים במכשירים ישנים יותר שלא יכולים להריץ את הגרסה העדכנית. כדאי לאמת את הנתונים באמצעות נתוני Analytics משלכם. אם עדיין לא הגדרתם ניתוח נתונים, מומלץ לעיין במאמר מעקב אחרי ביצועי התוסף באמצעות Google Analytics 4 כדי להתחיל.

משם, בוחרים נתיב:

התחלת השימוש באפשרות 'איסוף במועד מא

מגדירים minimum_chrome_version במניפסט ומשתמשים ב-browser ללא תנאי – אין צורך בהגנה בזמן ריצה:

{
  "minimum_chrome_version": "148"
}

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

שימוש באמצעי ההגנה בזמן הריצה

מוסיפים את קטע הקוד הבא מוקדם בקוד ההפעלה של התוסף, לפני שמפנים אל browser במקום אחר:

if (!globalThis.browser) {
  globalThis.browser = chrome;
  // Consider firing an analytics event here to measure how often
  // your users hit this fallback path.
}

בגרסאות קודמות, browser הוא שם חלופי ל-chrome, כך ששאר הקוד יכול להשתמש ב-browser ללא תנאי.

הערה למשתמשים ב-polyfill

אם התוסף משתמש ב-webextension-polyfill, הוא הופך ל-no-op ב-Chrome 148 ואילך. ה-polyfill דילג על העטיפה אם browser כבר הוגדר, מתוך הנחה שהדפדפן המארח כבר סיפק את ה-API.

ניסיון קודם להוסיף את מרחב השמות ב-Chrome 136 בוטל מהסיבה הבאה: עם browser שהוגדר לאחרונה, ה-polyfill הפסיק לעטוף, אבל browser.runtime.onMessage של Chrome עדיין לא תמך בהחזרת מאזינים של הבטחות, שה-polyfill סיפק. התוספים שמסתמכים על התבנית הזו הפסיקו לפעול. ‫Chrome 148 כולל את מרחב השמות ואת מאזיני onMessage שמחזירים הבטחה מקורית, כדי למנוע את הפער הזה.

אחרי שבסיס המשתמשים שלכם יעבור ל-Chrome 148, תוכלו להסיר את התלות ב-polyfill.

תכונות אחרות

תשובות אסינכרוניות ב-runtime.sendMessage

ב-Chrome 148, מאזינים runtime.onMessage יכולים להחזיר Promise ישירות כדי לשלוח תגובה אסינכרונית. הפונקציה הזו פועלת גם אם קוראים לה באמצעות chrome.* וגם אם באמצעות browser.*.

בעבר, הדרך היחידה להגיב באופן אסינכרוני הייתה להחזיר את הערך true מהמאזין ולהפעיל את sendResponse מאוחר יותר:

// Old pattern - requires returning true to keep the channel open
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  fetch('https://example.com')
    .then(response => sendResponse({ statusCode: response.status }));

  return true; // keeps the message channel open for the async response
});

עכשיו אפשר להחזיר Promise (או להשתמש בפונקציה async) ישירות:

// New pattern - return a promise or use async/await
browser.runtime.onMessage.addListener(async (message, sender) => {
  const response = await fetch('https://example.com');
  return { statusCode: response.status };
});

התבנית return true ממשיכה לפעול, כך שאין צורך לשנות את הקוד הקיים.