מאז ההשקה של תוספי Chrome, הפלטפורמה אפשרה למפתחים לחשוף את הפונקציונליות של התוספים ישירות בממשק המשתמש של Chrome ברמה העליונה באמצעות פעולות. פעולה היא לחצן סמל שיכול לפתוח חלון קופץ או להפעיל פונקציונליות מסוימת בתוסף. בעבר, דפדפן Chrome תמך בשני סוגים של פעולות: פעולות בדפדפן ופעולות בדפים. במניפסט V3 איחוד הפונקציונליות שלהן נעשה בממשק API חדש של chrome.action.
היסטוריה קצרה של פעולות לגבי תוספים
אמנם ה-chrome.action עצמו חדש במניפסט מגרסה 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" עשוי להיראות כמו שם חריג לפונקציונליות הזו, בהשוואה ל-"isAssociated", למשל, אבל היסטוריית הפעולות ב-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.
לבסוף, תוכנות לחסימת תוכן יכולות להשתמש בשיטה setExtensionActionOptions של declarativeNetRequest API כדי להציג את מספר הבקשות שנחסמו על ידי התוסף בכרטיסייה נתונה. היכולת הזו חשובה כי היא מאפשרת לחוסמי תוכן לעדכן את משתמשי הקצה בלי לחשוף לתוסף מטא-נתונים שעשויים להיות רגישים.
סיכום
אחד מהמניעים העיקריים שלנו במניפסט V3 היה פיתוח מודרני של פלטפורמת התוספים ל-Chrome. במקרים רבים היה צורך לעבור לטכנולוגיות חדשות, אבל המשמעות היא גם שפלטפורמת ה-API שלנו תהיה פשוטה יותר. זו הייתה המטרה שלנו.
אני מקווה שהפוסט הזה עזר לכם להבין את הפינה הספציפית הזו של פלטפורמת Manifest V3. במסמכי התיעוד למפתחים מפורט מידע נוסף על הגישה של צוות Chrome לעתיד של תוספי הדפדפן כדאי לעיין בדפים Platform Vision וסקירה כללית של Manifest V3. תוכלו גם לשוחח על תוספים ל-Chrome עם מפתחים אחרים בקבוצת Google של chromium-extensions.