Problemi noti relativi alla migrazione a Manifest V3

Questa pagina documenta le lacune della piattaforma risolte durante la transizione al manifest V3 e risponde alle domande frequenti sulla migrazione.

Lacune della piattaforma risolte

Sono state aggiunte le seguenti funzionalità per risolvere i problemi comuni di blocco della migrazione:

  1. Supporto per la gestione dei file su ChromeOS in sostituzione di chrome.fileBrowserHandler (Chrome 120).
  2. Supporto degli script utente:consente di registrare script dei contenuti con codice arbitrario con la nuova API userScripts (Chrome 120).
  3. Keepalive del service worker aggiuntivi per determinate operazioni che richiedono più di cinque minuti.
    • Aggiunta in Chrome 116 per permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() e management.uninstall().
    • Aggiunta in Chrome 118 per chrome.debugger.
  4. Aumenta il numero di set di regole statici e attivati per Declarative Net Request (DNR). I set di regole statici attivati sono aumentati da 10 a 50 e i set di regole statici totali da 50 a 100 (Chrome 120).
  5. Estendere la funzionalità Documento fuori schermo per supportare più motivi per l'utilizzo di un documento fuori schermo. Aggiunta di GEOLOCATION in Chrome 116.
  6. Miglioramento del supporto dell'API chrome.tabCapture (Chrome 116):
    • Supporto per le chiamate getMediaStreamId() da un service worker.
    • Supporta l'ottenimento di un MediaStream da un ID stream in un documento fuori schermo.
  7. Estensione della durata dei service worker mentre sono attive WebSocket connessioni (Chrome 116).

Domande frequenti su Manifest V3

D: Abbiamo intenzione di supportare i service worker persistenti?
R: Uno dei motivi principali per la migrazione dagli script di sfondo ai service worker è il modello di programmazione basato sugli eventi più efficiente in termini di memoria, che deriva dalla natura effimera dei service worker. Di conseguenza, non prevediamo di supportare i service worker persistenti. Tuttavia, per soddisfare le esigenze specifiche degli sviluppatori di estensioni, continuiamo a apportare molti miglioramenti ai service worker. In particolare:

  • Tutti gli eventi di estensione e le chiamate API estenderanno la durata del service worker.
  • Alcuni casi d'uso selezionati, come la messaggistica nativa, manterranno attivi i service worker delle estensioni per più di 5 minuti.

D: Esiste un modo per accedere al DOM nei service worker?
R: Seguiamo l'approccio adottato dalla piattaforma web di non includere l'accesso al DOM nei web worker (inclusi i service worker). Per supportare i casi d'uso che richiedono l'accesso al DOM in background dai service worker, abbiamo introdotto la possibilità di delegare il lavoro in background a documenti offscreen di breve durata che forniscono l'accesso completo al DOM.

D: Esiste un modo per supportare il codice remoto in Manifest V3?
R: Per rendere più sicure le estensioni di Chrome, continueremo a vietare l'esecuzione di codice ospitato in remoto arbitrario nelle estensioni di Chrome. Tuttavia, ciò non significa che non consentiamo tutti i tipi di esecuzione di codice dinamico. Continuiamo a supportare diverse opzioni di esecuzione dinamica del codice nelle estensioni Chrome:

D: La mia estensione Manifest V2 si basa su webRequestBlocking, che non è supportato in Manifest V3. Come posso continuare a fornire le stesse funzionalità in Manifest V3?
R: Siamo certi che la maggior parte dei casi d'uso di blocco delle richieste possa essere risolta con la nuova API declarativeNetRequest, che ha l'ulteriore vantaggio di evitare l'overhead delle prestazioni della comunicazione interprocesso, l'esecuzione del codice a ogni richiesta o la necessità di un processo di estensione attivo al momento della richiesta. Tuttavia, per i casi d'uso aziendali (o didattici) complessi, il blocco dinamico delle richieste è ancora supportato.

Ci è sfuggito qualcosa? Facci sapere.