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

Simeon Vincent

מאז ההשקה של תוספים ל-Chrome, הפלטפורמה אפשרה למפתחים לחשוף את התוסף פונקציונליות ישירות בממשק המשתמש ברמה העליונה של Chrome באמצעות פעולות. פעולה היא לחצן סמל יכול לפתוח חלון קופץ או להפעיל פונקציונליות מסוימת בתוסף. בעבר, Chrome תמך סוגים של פעולות, פעולות דפדפן ופעולות בדף. גרסה 3 של המניפסט שינתה את ההגדרה הזו על ידי איחוד של פונקציונליות ב-chrome.action API חדש.

היסטוריה קצרה של פעולות לתוספים

chrome.action עצמו חדש במניפסט מגרסה V3, אבל הפונקציונליות הבסיסית שהוא מספקת ועד מתי התוספים הגיעו למצב יציב בינואר 2010. היציבות הראשונה הגרסה של פלטפורמת התוספים של Chrome תמכה בשני סוגים שונים של פעולות: פעולות ופעולות בדף.

פעולות הדפדפן אפשרו למפתחי תוספים להציג סמל "בסרגל הכלים הראשי של Google Chrome, שמשמאל לסרגל הכתובות". (מקור) וסיפקו למשתמשים דרך קלה כדי להפעיל פונקציונליות של תוסף בכל דף. לעומת זאת, פעולות בדף נועדו "מייצגות פעולות שניתן לבצע בדף הנוכחי, אבל לא רלוונטיות לכל הדפים" (מקור).

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

שני סוגי הפעולות היו אופציונליים, כך שמפתח תוספים יכול לבחור לציין פעולות, פעולת דף או פעולת דפדפן (אסור לציין כמה פעולות).

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

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

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

שינויים במניפסט מגרסה V3

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

לסיום, חוסמי תוכן יכולים להשתמש ב-declarativeNetRequest API setExtensionActionOptions) כדי להציג את מספר בקשות שנחסמו על ידי התוסף לגבי כרטיסייה נתונה. היכולת הזו חשובה כי היא מאפשרת חסימת תוכן כדי לעדכן את משתמשי הקצה בלי לחשוף מטא-נתונים של גלישה שעלולים להיות רגישים לתוסף.

סיכום

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

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