Sinds de lancering van Chrome-extensies heeft het platform ontwikkelaars de mogelijkheid gegeven om de extensiefunctionaliteit rechtstreeks in de Chrome-gebruikersinterface op het hoogste niveau beschikbaar te maken met behulp van acties . Een actie is een pictogramknop die een pop-up kan openen of bepaalde functionaliteit in de extensie kan activeren. Historisch gezien ondersteunde Chrome twee soorten acties: browseracties en pagina-acties; Manifest V3 heeft dit veranderd door hun functionaliteit te consolideren in een nieuwe chrome.action API.
Een korte geschiedenis van uitbreidingsacties
Hoewel chrome.action zelf nieuw is in Manifest V3, dateert de basisfunctionaliteit die het biedt terug tot de tijd dat extensies in januari 2010 voor het eerst stabiel kwamen . De eerste stabiele release van het extensieplatform van Chrome ondersteunde twee verschillende soorten acties: browseracties en pagina-acties .
Dankzij browseracties konden ontwikkelaars van extensies een pictogram weergeven "in de hoofdwerkbalk van Google Chrome, rechts van de adresbalk" ( bron ) en konden gebruikers op een eenvoudige manier de extensiefunctionaliteit op elke pagina activeren. Pagina-acties waren daarentegen bedoeld om "acties weer te geven die op de huidige pagina kunnen worden uitgevoerd, maar die niet op alle pagina's van toepassing zijn" ( bron ).
Met andere woorden: browseracties gaven ontwikkelaars van extensies een blijvend UI-oppervlak in de browser, terwijl pagina-acties alleen verschenen als de extensie iets nuttigs kon doen op de huidige pagina.
Beide soorten acties waren optioneel, dus een extensie-ontwikkelaar kon ervoor kiezen om geen acties, een paginaactie of een browseractie op te geven (het opgeven van meerdere acties is niet toegestaan).
Ongeveer zes jaar later introduceerde Chrome 49 een nieuw UI-paradigma voor extensies. Om gebruikers te helpen begrijpen welke extensies ze hadden, begon Chrome alle actieve extensies rechts van de omnibox weer te geven. Gebruikers kunnen desgewenst extensies in het Chrome-menu laten overlopen.
Om voor elke extensie een pictogram weer te geven, luidde deze update ook twee belangrijke veranderingen in in de manier waarop extensies zich gedroegen in de gebruikersinterface van Chrome. Ten eerste begonnen alle extensies pictogrammen in de werkbalk weer te geven. Als de extensie geen pictogram had, zou Chrome er automatisch een voor genereren. Ten tweede werden pagina-acties naast browseracties naar de werkbalk verplaatst en kregen ze de mogelijkheid om onderscheid te maken tussen hun 'toon'- en 'verberg'-status.
Door deze wijziging konden pagina-actie-extensies blijven werken zoals verwacht, maar werd in de loop van de tijd ook de rol van pagina-acties kleiner. Een van de effecten van het herontwerp van de gebruikersinterface was dat paginaacties effectief werden ondergebracht in browseracties. Omdat alle extensies in de werkbalk verschenen, gingen gebruikers verwachten dat klikken op het werkbalkpictogram van een extensie de extensie zou oproepen, en browseracties werden een steeds belangrijkere interactie voor Chrome-extensies.
Duidelijke V3-veranderingen
De gebruikersinterface en extensies van Chrome bleven zich ontwikkelen in de jaren na het herontwerp van de gebruikersinterface van de extensie in 2016, maar browseracties en pagina-acties bleven grotendeels ongewijzigd. Dat wil zeggen, tenminste totdat we begonnen te plannen hoe we het uitbreidingsplatform met Manifest V3 zouden moderniseren.
Het was voor het extensieteam duidelijk dat browseracties en paginaacties steeds meer een onderscheid zonder betekenis waren. Erger nog, hun subtiele gedragsverschillen maakten het voor ontwikkelaars moeilijk om te bepalen welke ze moesten gebruiken. We realiseerden ons dat we deze problemen konden aanpakken door de browseractie en paginaactie te combineren in één enkele 'actie'.
Voer de Actie-API in; chrome.action is het meest direct analoog aan chrome.browserAction , maar heeft een paar opmerkelijke verschillen.
Ten eerste introduceert chrome.action een nieuwe methode genaamd getUserSettings() . Met deze methode kunnen ontwikkelaars van extensies controleren of de gebruiker de actie van hun extensie op de werkbalk heeft vastgezet.
let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);
"getUserSettings" lijkt misschien een beetje een ongebruikelijke naam voor deze functionaliteit vergeleken met bijvoorbeeld "isPinned", maar de geschiedenis van acties in Chrome laat zien dat de gebruikersinterface van de browser sneller verandert dan extensie-API's. Daarom is ons doel met deze API om actiegerelateerde gebruikersvoorkeuren op generieke interfaces bloot te leggen om het toekomstige API-verloop te minimaliseren. Het stelt andere browserleveranciers ook in staat browserspecifieke UI-concepten bloot te leggen in het UserSettings- object dat door deze methode wordt geretourneerd.
Ten tweede kunnen het pictogram en de ingeschakelde/uitgeschakelde status van de actie van een extensie worden beheerd met behulp van de Declarative Content API. Dit is belangrijk omdat extensies kunnen reageren op het surfgedrag van de gebruiker zonder toegang te krijgen tot de inhoud of zelfs tot de URL's van de pagina's die ze bezoeken. Laten we bijvoorbeeld eens kijken hoe een extensie actie kan ondernemen wanneer de gebruiker pagina's op example.com bezoekt.
// 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()]
}
]);
});
});
De bovenstaande code is vrijwel identiek aan wat een extensie zou doen met een paginaactie. Het enige verschil is dat we in Manifest V3 declarativeContent.ShowAction gebruikten in plaats van declarativeContent.ShowPageAction in Manifest V2.
Ten slotte kunnen inhoudblokkers de methode setExtensionActionOptions van de declarativeNetRequest API gebruiken om het aantal verzoeken weer te geven dat door de extensie voor een bepaald tabblad is geblokkeerd. Deze mogelijkheid is belangrijk omdat inhoudblokkers hiermee eindgebruikers op de hoogte kunnen houden zonder potentieel gevoelige browse-metagegevens aan de extensie bloot te stellen.
Sluit af
Het moderniseren van het Chrome-extensieplatform was een van onze belangrijkste motivaties voor Manifest V3. In veel gevallen betekende dit dat we moesten overstappen op nieuwe technologieën, maar het betekende ook dat we ons API-oppervlak moesten vereenvoudigen; dat is wat ons doel hier was.
Ik hoop dat dit bericht enig licht heeft geworpen op deze specifieke hoek van het Manifest V3-platform. Voor meer informatie over hoe het Chrome-team de toekomst van browserextensies benadert, bekijk de Platformvisie en Overzicht van Manifest V3 -pagina's in onze ontwikkelaarsdocumentatie. Je kunt Chrome-extensies ook bespreken met andere ontwikkelaars in de Chrome-extensies Google Group.