מאז ההשקה של תוספים ל-Chrome, הפלטפורמה מאפשרת למפתחים לחשוף את הפונקציונליות של התוספים ישירות בממשק המשתמש של Chrome ברמה העליונה באמצעות פעולות. פעולה היא לחצן סמל שיכול לפתוח חלון קופץ או להפעיל פונקציונליות מסוימת בתוסף. בעבר, Chrome תמך בשני סוגים של פעולות: פעולות דפדפן ופעולות בדפים; שינוי זה השתנה במניפסט מגרסה V3 על ידי איחוד הפונקציונליות שלו בממשק API חדש מסוג chrome.action.
היסטוריה קצרה של פעולות לתוספים
האפשרות chrome.action עצמה חדשה ב-Manifest V3, אבל הפונקציונליות הבסיסית שהיא מספקת קיימת מאז השקת התוספים בגרסה יציבה בינואר 2010. הגרסה היציבה הראשונה של פלטפורמת התוספים של Chrome תמכה בשני סוגים שונים של פעולות: פעולות בדפדפן ופעולות בדף.
פעולות בדפדפן אפשרו למפתחי התוספים להציג סמל "בסרגל הכלים הראשי של Google Chrome, שמשמאל לסרגל הכתובות" (מקור), וסיפקו למשתמשים דרך קלה להפעיל את הפונקציונליות של התוסף בכל דף. לעומת זאת, פעולות בדף נועדו "לייצג פעולות שאפשר לבצע בדף הנוכחי, אבל לא רלוונטיות לכל הדפים" (מקור).
במילים אחרות, פעולות בדפדפן העניקו למפתחי התוספים ממשק משתמש קבוע בדפדפן, ואילו פעולות בדף הופיעו רק כשהתוסף יכול היה לבצע פעולה שימושית בדף הנוכחי.
שני סוגי הפעולות היו אופציונליים, כך שמפתחי התוספים יכלו לבחור לא לספק אף פעולה, פעולת דף או פעולת דפדפן (לא ניתן לציין כמה פעולות).
כשש שנים לאחר מכן, ב-Chrome 49 הושקה פרדיגמה חדשה של ממשק המשתמש לתוספים. כדי לעזור למשתמשים להבין אילו תוספים מותקנים אצלם, התחלנו להציג את כל התוספים הפעילים ב-Chrome משמאל לסרגל החיפוש הכללי. המשתמשים יכלו להוסיף תוספים לתפריט Chrome אם הם רצו.
כדי להציג סמל לכל תוסף, העדכון הזה התבצע גם בשני שינויים חשובים בהתנהגות התוספים בממשק המשתמש של Chrome. ראשית, כל התוספים התחילו להציג סמלים בסרגל הכלים. אם לתוסף אין סמל, Chrome ייצור סמל עבורו באופן אוטומטי. שנית, פעולות הדף הועברו לסרגל הכלים לצד פעולות הדפדפן, והן קיבלו תכונה שמאפשרת להבדיל בין המצבים 'הצגה' ו'הסתרה'.
השינוי הזה איפשר לתוספים של פעולות בדף להמשיך לפעול כצפוי, אבל הוא גם צמצם את התפקיד של פעולות בדף לאורך זמן. אחד ההשפעות של העיצוב מחדש של ממשק המשתמש היה שהפעולות בדף מבוססות בפועל על פעולות בדפדפן. מכיוון שכל התוספים הופיעו בסרגל הכלים, המשתמשים ציפו שלחיצה על סמל התוסף בסרגל הכלים תפעיל את התוסף, ופעולות בדפדפן הפכו לאינטראקציה חשובה יותר ויותר עבור תוספי Chrome.
שינויים במניפסט V3
ממשק המשתמש והתוספים של Chrome המשיכו להתפתח בשנים שלאחר עיצוב הממשק מחדש של התוספים ב-2016, אבל פעולות הדפדפן ופעולות הדף לא השתנו במידה רבה. כלומר, לפחות עד שהתחלנו לתכנן איך לחדש את פלטפורמת התוספים באמצעות Manifest V3.
לצוות התוספים היה ברור שההבחנה בין פעולות בדפדפן לבין פעולות בדף הולכת ונעשית חסרת משמעות. גרוע מכך, ההבדלים העדינים בהתנהגות שלהם הקשו על המפתחים לקבוע באיזה מהם להשתמש. הבנו שאפשר לטפל בבעיות האלה על ידי שילוב הפעולה בדפדפן והפעולה בדף ל'פעולה' אחת.
נכנסים ל-Action API. chrome.action הוא הדומה ביותר ל-chrome.browserAction, אבל יש לו כמה הבדלים משמעותיים.
קודם כול, chrome.action מציגה שיטה חדשה בשם getUserSettings(). השיטה הזו מאפשרת למפתחי התוספים לבדוק אם המשתמש הצמיד את הפעולה של התוסף לסרגל הכלים.
let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);
יכול להיות ש-'getUserSettings' שם נראה קצת יוצא דופן לפונקציונליות הזו בהשוואה ל-'isPinned' (למשל, מוצמד), אבל היסטוריית הפעולות ב-Chrome מראה שממשק המשתמש של הדפדפן משתנה מהר יותר מאשר ממשקי API של תוספים. לכן, המטרה שלנו ב-API הזה היא לחשוף העדפות משתמשים שקשורות לפעולות בממשקים כלליים כדי לצמצם נטישה עתידית של API. היא גם מאפשרת לספקי דפדפנים אחרים לחשוף מושגים של ממשק משתמש ספציפי לדפדפן באובייקט UserSettings שמוחזר על ידי השיטה הזו.
שנית, אפשר לשלוט בסמל ובמצב מופעל/מושבת של הפעולה של התוסף באמצעות Declarative Content API. זה חשוב כי כך התוספים יכולים להגיב להתנהגות הגלישה של המשתמשים בלי לגשת לתוכן או אפילו לכתובות ה-URL של הדפים שבהם הם מבקרים. לדוגמה, נראה איך תוסף יכול להפעיל את הפעולה שלו כשהמשתמש מבקר בדפים בכתובת example.com.
// Manifest V3
chrome.runtime.onInstalled.addListener(() => {
chrome.declarativeContent.onPageChanged.removeRules(undefined, () => {
chrome.declarativeContent.onPageChanged.addRules([
{
conditions: [
new chrome.declarativeContent.PageStateMatcher({
pageUrl: {hostSuffix: '.example.com'},
})
],
actions: [new chrome.declarativeContent.ShowAction()]
}
]);
});
});
הקוד שלמעלה זהה כמעט למה שתוסף היה עושה עם פעולת דף. ההבדל היחיד הוא שבמניפסט מגרסה V3 השתמשנו ב-declarativeContent.ShowAction במקום ב-declarativeContent.ShowPageAction במניפסט מגרסה V2.
לסיום, חוסמי התוכן יכולים להשתמש ב-method setExtensionActionOptions של declarativeNetRequest API כדי להציג את מספר הבקשות שהתוסף חסם בכרטיסייה מסוימת. היכולת הזו חשובה כי היא מאפשרת לחוסמי תוכן לעדכן את משתמשי הקצה בלי לחשוף למפַתח את המטא-נתונים של הגלישה שעשויים להיות רגישים.
סיכום
אחד מהמניעים העיקריים שלנו ליצירת Manifest V3 היה עדכון הפלטפורמה של התוספים ל-Chrome. במקרים רבים, המעבר כלל שימוש בטכנולוגיות חדשות, אבל הוא גם כלל פישוט של ממשק ה-API. זה היה היעד שלנו.
אני מקווה שהפוסט הזה עזר לך להבין את הפינה המסוימת הזו של פלטפורמת Manifest V3. כדי לקבל מידע נוסף על האופן שבו צוות Chrome מתכנן את העתיד של תוספים לדפדפנים, אפשר לעיין בדפים חזון הפלטפורמה וסקירה כללית על Manifest V3 במסמכי התיעוד למפתחים. אפשר גם לדון על תוספים ל-Chrome עם מפתחים אחרים בקבוצת Google chromium-extensions.