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

החל מ-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 מתעדכן אוטומטית, אבל חלק מהמשתמשים משביתים את העדכונים, ואחרים משתמשים במכשירים ישנים יותר שלא יכולים להריץ את הגרסה העדכנית. כדאי לאמת את הנתונים באמצעות נתוני ניתוח משלכם. אם עדיין לא הגדרתם ניתוח נתונים, מומלץ לעיין במאמר מעקב אחרי ביצועי התוסף באמצעות 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, הוא הופך ללא פעיל ב-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 ממשיכה לפעול, כך שלא צריך לשנות את הקוד הקיים.