Overgang naar browsernaamruimte

Vanaf Chrome 148 zijn alle Chrome Extension API's beschikbaar in de namespace browser , naast de bestaande namespace chrome . Zo zijn browser.tabs.create({}) en chrome.tabs.create({}) bijvoorbeeld equivalent.

De namespace is beschikbaar overal waar je extensie-API's kunt aanroepen, inclusief contentscripts, serviceworkers en offscreen-documenten. Het verwijst naar dezelfde API-objecten als chrome , dus chrome.tabs === browser.tabs .

De browser namespace is voortgekomen uit werk van de WebExtensions Community Group (WECG) , een W3C-communitygroep waar browserleveranciers samenwerken aan gedeelde extensiestandaarden. De chrome namespace verdwijnt niet; beide namespaces blijven functioneren.

Extensies met een DevTools-pagina kunnen de browser naamruimte niet gebruiken. Als uw extensie een `devtools_page` declareert, wordt de browser naamruimte voor de hele extensie uitgeschakeld - niet alleen voor de DevTools-pagina, maar ook voor uw service worker, content scripts, pop-up, optiepagina en elke andere context waarin extensie-API's worden uitgevoerd. Blijf chrome.* gebruiken in deze extensies. Zie De browser-naamruimte en DevTools-extensies voor meer informatie hierover.

Besluit of je de browsernaamruimte wilt overnemen.

Als je webextension-polyfill gebruikt, ga dan verder naar 'Een opmerking voor polyfill-gebruikers' voordat je iets anders wijzigt - het antwoord is anders voor jou.

Als je een nieuwe extensie bouwt, stel dan minimum_chrome_version in op "148" en gebruik browser unconditionally; je kunt hier stoppen met lezen. De rest van dit gedeelte is bedoeld voor bestaande extensies die willen beslissen hoe ze dit willen implementeren.

Controleer welke Chrome-versies uw gebruikers gebruiken.

Als je al een extensie hebt, controleer dan welke Chrome-versies je gebruikers gebruiken voordat je overschakelt. Chrome wordt automatisch bijgewerkt, maar sommige gebruikers schakelen updates uit en anderen gebruiken oudere apparaten die de nieuwste versie niet aankunnen. Bevestig dit met je eigen analysegegevens. Als je nog geen analyses hebt ingesteld, raadpleeg dan 'De prestaties van je extensie monitoren met Google Analytics 4' om aan de slag te gaan.

Kies van daaruit een pad:

• Als uw gebruikers Chrome versie 148 of later gebruiken , neem deze functie dan zonder voorbehoud over .
• Als een aanzienlijk deel van uw gebruikers Chrome 147 of ouder gebruikt , gebruik dan de runtime guard .

Adopteer zonder voorwaarden

Stel minimum_chrome_version in je manifest in en gebruik browser onvoorwaardelijk - er is geen runtime guard nodig:

{
  "minimum_chrome_version": "148"
}

Door minimum_chrome_version in te stellen, worden alle updates voor gebruikers met een oudere Chrome-versie stopgezet. De Chrome Web Store levert geen toekomstige versies van uw extensie meer aan gebruikers met een oudere versie dan de door u opgegeven versie. Zij blijven op de versie die ze hebben geïnstalleerd en ontvangen geen bugfixes, beveiligingspatches of nieuwe functies, tenzij ze Chrome bijwerken. Dit is vaak de juiste keuze, maar beschouw het als een weloverwogen beslissing en niet als een standaard compatibiliteitsinstelling.

Gebruik een gefaseerde uitrol wanneer je minimum_chrome_version verhoogt. Als er iets misgaat, kun je je extensie terugdraaien in de Chrome Web Store.

Gebruik de runtime guard

Voeg het volgende codefragment vroeg in de opstartcode van uw extensie toe, voordat u ergens anders naar browser verwijst:

if (!globalThis.browser) {
  globalThis.browser = chrome;
  // Consider firing an analytics event here to measure how often
  // your users hit this fallback path.
}

Hierdoor wordt browser een alias voor chrome in eerdere versies, zodat de rest van je code browser onvoorwaardelijk kan gebruiken.

Een mededeling voor gebruikers van polyfills

Als uw extensie gebruikmaakt van webextension-polyfill , heeft dit geen effect meer in Chrome 148 en latere versies. De polyfill slaat het inpakken over wanneer browser al gedefinieerd is, ervan uitgaande dat de hostbrowser de API al beschikbaar heeft gesteld.

Een eerdere poging om de namespace in Chrome 136 te implementeren werd om de volgende reden teruggedraaid: met de nieuwe definitie browser stopte de polyfill met het inpakken van de code, maar Chrome's ` browser.runtime.onMessage ondersteunde nog geen listeners die een promise teruggeven, iets wat de polyfill wel deed. Extensies die op dat patroon vertrouwden, werkten daardoor niet meer. Chrome 148 levert de namespace en native onMessage -listeners die een promise teruggeven samen om dit probleem op te lossen.

Je kunt de polyfill-afhankelijkheid verwijderen zodra je gebruikers zijn overgestapt naar Chrome 148.

Overige kenmerken

Asynchrone reacties in runtime.sendMessage

In Chrome 148 kunnen runtime.onMessage listeners rechtstreeks een Promise retourneren om een ​​asynchrone reactie te verzenden. Dit werkt ongeacht of je de methode aanroept met chrome.* of browser.* .

Voorheen was de enige manier om asynchroon te reageren, het retourneren van een letterlijke true vanuit de listener en het later aanroepen sendResponse :

// Old pattern - requires returning true to keep the channel open
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  fetch('https://example.com')
    .then(response => sendResponse({ statusCode: response.status }));

  return true; // keeps the message channel open for the async response
});

Je kunt nu rechtstreeks een Promise retourneren (of een async functie gebruiken):

// New pattern - return a promise or use async/await
browser.runtime.onMessage.addListener(async (message, sender) => {
  const response = await fetch('https://example.com');
  return { statusCode: response.status };
});

Het return true patroon blijft werken, dus bestaande code hoeft niet te worden aangepast.

Net als bij de browser zelf, zijn Promise-reacties runtime.onMessage niet beschikbaar in extensies die een `devtools_page` declareren.