منذ إطلاق إضافات Chrome، أتاح النظام الأساسي للمطوّرين عرض وظائف الإضافات مباشرةً في واجهة مستخدم Chrome ذات المستوى الأعلى باستخدام actions (الإجراءات). الإجراء هو زر أيقونة يمكنه فتح نافذة منبثقة أو تشغيل بعض الوظائف في الإضافة. في السابق، كان Chrome يدعم نوعين من الإجراءات، هما إجراءات المتصفّح وإجراءات الصفحة. وقد غيّر إصدار Manifest V3 ذلك من خلال دمج وظائفهم في واجهة برمجة تطبيقات chrome.action جديدة.
سجلّ موجز من إجراءات الإضافات
رغم أنّ chrome.action نفسه جديد في إصدار Manifest V3، فإنّ الوظيفة الأساسية التي يوفرها تعود إلى تاريخ وضع الإضافات في وضع مستقر في كانون الثاني (يناير) 2010. كان أول إصدار ثابت من نظام إضافات Chrome يعتمد نوعين مختلفين من الإجراءات: إجراءات المتصفّح وإجراءات الصفحة.
أتاحت إجراءات المتصفّح لمطوّري الإضافات عرض رمز "في شريط أدوات Google Chrome الرئيسي، على يسار شريط العناوين" (المصدر)، ووفّرت للمستخدمين طريقة سهلة لتشغيل وظائف الإضافات على أي صفحة. من ناحية أخرى، كان الهدف من إجراءات الصفحة هو "تمثيل الإجراءات التي يمكن اتخاذها على الصفحة الحالية، ولكنها لا تنطبق على جميع الصفحات" (المصدر).
بمعنى آخر، منحت إجراءات المتصفّح مطوّري الإضافات مساحة عرض دائمة لواجهة المستخدم في المتصفّح، بينما كانت إجراءات الصفحة تظهر فقط عندما تقدّم الإضافة إجراءً مفيدًا على الصفحة الحالية.
كان كلا نوعَي الإجراءات اختياريًا، لذلك يمكن لمطوِّر الإضافات اختيار عدم تقديم إجراءات أو إجراء على الصفحة أو إجراء متصفّح (لا يُسمح بتحديد إجراءات متعددة).
بعد ست سنوات تقريبًا، قدّم Chrome 49 نموذجًا جديدًا لواجهة المستخدم للإضافات. من أجل مساعدة المستخدمين على فهم الإضافات التي لديهم، بدأ Chrome في عرض جميع الإضافات النشطة على يمين المربّع المتعدد الاستخدامات. ويمكن للمستخدمين "تجاوز" الإضافات في قائمة Chrome إذا أرادوا.
ولعرض رمز لكل إضافة، أطلق هذا التحديث أيضًا تغييرين مهمين بشأن طريقة عمل الإضافات في واجهة المستخدم في Chrome. أولاً، بدأت جميع الإضافات في عرض الأيقونات في شريط الأدوات. إذا لم تكن الإضافة تحتوي على رمز، سيُنشئ Chrome رمزًا لها تلقائيًا. ثانيًا، تم نقل إجراءات الصفحة إلى شريط الأدوات إلى جانب إجراءات المتصفح وتم منحها القدرة على التمييز بين حالة "العرض" و "الإخفاء".
سمح هذا التغيير لإضافات إجراءات الصفحة بمواصلة العمل كما هو متوقع، ولكنه قلل أيضًا من دور إجراءات الصفحة بمرور الوقت. وكان أحد تأثيرات إعادة تصميم واجهة المستخدم أن إجراءات الصفحة تم افتراضها بشكل فعال من خلال إجراءات المتصفح. وبما أنّ جميع الإضافات تظهر في شريط الأدوات، اعتقد المستخدمون أنّ النقر على رمز شريط أدوات الإضافة سيؤدي إلى استدعاء الإضافة، وستصبح إجراءات المتصفّح تفاعلاً مهمًا بشكل متزايد لإضافات Chrome.
التغييرات في إصدار Manifest 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" اسمًا غير مألوف لهذه الوظيفة مقارنةً بـ "isInstall" على سبيل المثال، إلا أنّ سجل الإجراءات في Chrome يُظهر أنّ واجهة المستخدم في المتصفح تتغيّر بشكل أسرع من واجهات برمجة التطبيقات للإضافات. وبالتالي، يتمثّل هدفنا من خلال واجهة برمجة التطبيقات هذه في الكشف عن الإعدادات المفضّلة للمستخدم المتعلّقة بالإجراءات على الواجهات العامة للحدّ من إيقاف استخدام واجهات برمجة التطبيقات في المستقبل. ويسمح هذا الإجراء أيضًا لمورّدي المتصفِّح الآخرين بعرض مفاهيم واجهة المستخدم الخاصة بالمتصفِّح في كائن 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()]
}
]);
});
});
الرمز أعلاه يماثل تقريبًا ما ستفعله الإضافة مع إجراء الصفحة. الفرق الوحيد هو أنه تم استخدام declarativeContent.ShowAction في Manifest V3 بدلاً من declarativeContent.ShowPageAction في Manifest V2.
أخيرًا، يمكن لبرامج حظر المحتوى استخدام طريقة declarativeNetRequest API
setExtensionActionOptions) لعرض عدد الطلبات التي تحظرها الإضافة لعلامة تبويب محدَّدة. وهذه الإمكانية مهمة لأنها تسمح لبرامج حظر المحتوى بإبقاء المستخدمين النهائيين على علم بآخر الأخبار بدون عرض بيانات التصفح التي قد تكون حساسة
للإضافة.
الخاتمة
كان تحديث النظام الأساسي لإضافات Chrome أحد دوافعنا الرئيسية لإصدار Manifest V3. في العديد من الحالات، كان يعني ذلك التبديل إلى تكنولوجيات جديدة، ولكنه كان يعني أيضًا تبسيط واجهة برمجة التطبيقات لدينا؛ هذا ما كان هدفنا هنا.
نأمل أن تكون هذه المشاركة قد ساعدت في تسليط الضوء على هذه النقطة المحدّدة من منصة Manifest V3. لمعرفة المزيد من المعلومات عن كيفية تعامل فريق Chrome مع مستقبل إضافات المتصفّح، يمكنك الاطّلاع على صفحتَي رؤية النظام الأساسي ونظرة عامة على الإصدار 3 من ملف البيان في مستندات المطوّرين. يمكنك أيضًا مناقشة إضافات Chrome مع مطوّري البرامج الآخرين في مجموعة Google chromium-extensions.