Sinds de lancering van Chrome-extensies biedt het platform ontwikkelaars de mogelijkheid om de functionaliteit van extensies direct in de bovenste Chrome-gebruikersinterface weer te geven met behulp van acties . Een actie is een pictogramknop die een pop-up kan openen of bepaalde functionaliteit in de extensie kan activeren. Voorheen ondersteunde Chrome twee soorten acties: browseracties en pagina-acties; Manifest V3 heeft dit veranderd door de 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 uit de tijd dat extensies voor het eerst in de stabiele versie verschenen in januari 2010. De eerste stabiele versie van het extensieplatform van Chrome ondersteunde twee verschillende soorten acties: browseracties en pagina-acties .
Browseracties stelden ontwikkelaars van extensies in staat een pictogram weer te geven "in de hoofdwerkbalk van Google Chrome, rechts van de adresbalk" ( bron ) en boden gebruikers een eenvoudige manier om de functionaliteit van extensies op elke pagina te activeren. Paginaacties daarentegen waren 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 boden extensieontwikkelaars een blijvend gebruikersinterfaceoppervlak in de browser, terwijl pagina-acties alleen werden weergegeven als de extensie iets nuttigs kon doen op de huidige pagina.
Beide typen acties waren optioneel, dus een extensieontwikkelaar kon ervoor kiezen om geen acties, een pagina-actie of een browser-actie op te geven (het opgeven van meerdere acties is niet toegestaan).
Ongeveer zes jaar later introduceerde Chrome 49 een nieuw gebruikersinterfaceparadigma voor extensies. Om gebruikers te helpen begrijpen welke extensies ze hadden, begon Chrome alle actieve extensies rechts van de omnibox weer te geven. Gebruikers konden extensies desgewenst 'overflowen' naar het Chrome-menu.
Om voor elke extensie een pictogram weer te geven, introduceerde deze update ook twee belangrijke wijzigingen in de manier waarop extensies zich gedroegen in de gebruikersinterface van Chrome. Ten eerste begonnen alle extensies pictogrammen weer te geven in de werkbalk. Als de extensie geen pictogram had, genereerde Chrome er automatisch een. Ten tweede werden pagina-acties verplaatst naar de werkbalk, naast browseracties, en kregen ze de mogelijkheid om onderscheid te maken tussen hun 'weergeven' en 'verbergen'-status.
Deze wijziging zorgde ervoor dat pagina-actie-extensies bleven werken zoals verwacht, maar verminderde ook de rol van pagina-acties na verloop van tijd. Een van de gevolgen van het nieuwe gebruikersinterfaceontwerp was dat pagina-acties effectief werden overschaduwd door browseracties. Omdat alle extensies in de werkbalk verschenen, gingen gebruikers ervan uit dat klikken op het werkbalkpictogram van een extensie de extensie activeerde, en werden browseracties een steeds belangrijkere interactie voor Chrome-extensies.
Wijzigingen in Manifest V3
De Chrome-gebruikersinterface en -extensies bleven zich in de jaren na het nieuwe ontwerp van de extensie-gebruikersinterface in 2016 verder ontwikkelen, maar browseracties en pagina-acties bleven grotendeels ongewijzigd. Tenminste, totdat we begonnen met het plannen van de modernisering van het extensieplatform met Manifest V3.
Het extensieteam was duidelijk dat browseracties en paginaacties steeds meer een betekenisloos onderscheid vormden. Sterker 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 tot één 'actie'.
Maak kennis met de Action API; chrome.action is het meest analoog aan chrome.browserAction , maar er zijn een paar opvallende verschillen.
Ten eerste introduceert chrome.action een nieuwe methode genaamd getUserSettings() . Deze methode biedt extensieontwikkelaars een manier om te controleren of de gebruiker de actie van hun extensie aan de werkbalk heeft vastgezet.
let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);
"getUserSettings" lijkt misschien een wat vreemde naam voor deze functionaliteit in vergelijking met bijvoorbeeld "isPinned", maar de geschiedenis van acties in Chrome laat zien dat de browserinterface sneller verandert dan extensie-API's. Ons doel met deze API is dan ook om actiegerelateerde gebruikersvoorkeuren op generieke interfaces weer te geven om toekomstige API-churn te minimaliseren. Het stelt andere browserleveranciers ook in staat om browserspecifieke UI-concepten weer te geven 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 de Declarative Content API. Dit is belangrijk omdat extensies hiermee kunnen reageren op het surfgedrag van de gebruiker zonder toegang te hebben tot de content of zelfs de URL's van de bezochte pagina's. Laten we bijvoorbeeld eens kijken hoe een extensie zijn actie kan inschakelen 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 pagina-actie. Het enige verschil is dat we in Manifest V3 declarativeContent.ShowAction gebruikten in plaats van declarativeContent.ShowPageAction in Manifest V2.
Ten slotte kunnen contentblokkers de setExtensionActionOptions -methode 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 contentblokkers hiermee eindgebruikers op de hoogte kunnen houden zonder mogelijk gevoelige browsemetadata aan de extensie bloot te stellen.
Afronden
Het moderniseren van het Chrome-extensieplatform was een van onze belangrijkste drijfveren voor Manifest V3. In veel gevallen betekende dat de overstap naar nieuwe technologieën, maar het betekende ook het vereenvoudigen van ons API-platform; dat was ons doel.
Ik hoop dat dit bericht wat licht heeft geworpen op dit specifieke aspect van het Manifest V3-platform. Voor meer informatie over hoe het Chrome-team de toekomst van browserextensies benadert, bekijk de pagina's Platformvisie en Overzicht van Manifest V3 in onze documentatie voor ontwikkelaars. Je kunt ook Chrome-extensies bespreken met andere ontwikkelaars in de chromium-extensions Google Group.