Per sostituire la funzionalità durante la transizione dalle pagine in background ai service worker delle estensioni, gli sviluppatori possono utilizzare l'API chrome.offscreen e l'autorizzazione manifest a partire da Chrome 109. La richiesta di questa autorizzazione consente la creazione di documenti off-screen per l'utilizzo delle API DOM senza aprire in modo invadente nuove finestre o schede che interrompono l'esperienza utente. L'API chrome.offscreen è ora disponibile nelle estensioni di Chrome.
In Chromium, le estensioni Manifest V3 sono basate su service worker, ma questi ultimi non supportano le stesse API e gli stessi meccanismi delle pagine complete basate su documenti (che includono pagine in background ed eventi). Inoltre, l'utilizzo di script di contenuti per accedere alle API DOM nelle pagine web lascia l'estensione in balia di diversi criteri di sicurezza dei contenuti su base pagina. Per risolvere il problema, stiamo introducendo i documenti offscreen per supportare le API e le funzionalità relative al DOM consentendo alle estensioni Manifest V3 di aprire documenti offscreen minimi, con ambito e relativamente senza autorizzazioni in fase di esecuzione tramite un'API dedicata.
Informazioni sulla funzionalità
Poiché i documenti offscreen sono progettati specificamente per gestire casi d'uso non supportati nei service worker (ad esempio la riproduzione audio), la durata di questa pagina e le autorizzazioni che verranno concesse sono separate da quelle del service worker dell'estensione.
La pagina avrà un meccanismo di durata simile a quello delle pagine di evento in Manifest 2.0, in quanto verrà rimossa quando smetterà di eseguire azioni. Inoltre, l'agente utente può applicare ulteriori limitazioni alla durata specifica per lo scopo specificato.
I documenti offscreen sono progettati per colmare le lacune delle API accessibili solo alle API DOM. Per questo motivo, le API di estensione non devono essere esposte direttamente in questo contesto. Per ridurre la probabilità che le estensioni le utilizzino come "sostituzione della pagina in background", solo le API di messaggistica di chrome.runtime sono esposte al documento offscreen. Gli sviluppatori possono anche utilizzare la messaggistica web rivendicando il documento offscreen come client tramite il proprio service worker.
Poiché alcuni casi d'uso, in particolare lo scraping dei siti, richiedono l'accesso a frame cross-origin, consentiamo a questi documenti di incorporare frame cross-origin seguendo le stesse regole attualmente in vigore per le pagine delle estensioni. Nei documenti offscreen, gli script di contenuti specificati dall'estensione possono essere eseguiti in questi frame per estrarre i contenuti necessari, come per qualsiasi pagina web normale.
Motivi e scopo obbligatori
La creazione di un documento offscreen richiede motivi dichiarati e ulteriori giustificazioni. Questi motivi sono elencati nella documentazione di riferimento dell'API e gestiscono la durata del documento in modi diversi. Ad esempio, a un documento aperto per la riproduzione audio vengono attualmente applicate regole diverse rispetto a quelle applicate a un documento aperto per la gestione della clipboard. Puoi anche aggiungere ulteriori dettagli sullo scopo del documento offscreen nella giustificazione, che è una stringa scritta dallo sviluppatore e non un parametro con effetti sul documento. Nel tempo, man mano che gli sviluppatori condividono i loro feedback e casi d'uso, all'API potrebbero essere aggiunti ulteriori motivi.
Uno sguardo al futuro
Per facilitare l'implementazione, la prima versione di questa API supporta una sola pagina per estensione e profilo alla volta. Nelle versioni future, potremmo allentare questa limitazione per supportare più pagine. Al momento, se l'estensione è in esecuzione in modalità divisa con un profilo in incognito attivo, sia il profilo normale che quello in incognito possono avere ciascuno un documento offscreen. È inoltre previsto di fornire al worker dell'estensione la funzionalità DOM in un secondo momento. Puoi "predisporre le tue estensioni per il futuro" accoppiando le funzioni che utilizzano l'API offscreen con una funzione commentata equivalente nel service worker per lo scambio in un secondo momento.
// Solution 1 - Service workers cannot directly interact with
// the system clipboard. To work around this, we'll create an offscreen
// document and pass the data we want to write to the clipboard.
async function addToClipboard(value) {
await chrome.offscreen.createDocument({
url: 'offscreen.html',
reasons: [chrome.offscreen.Reason.CLIPBOARD],
justification: 'Write text to the clipboard.',
});
}
// Solution 2 – Once extension service workers can use the Clipboard API,
// replace the offscreen document based implementation with something like this
async function addToClipboardV2(value) {
navigator.clipboard.writeText(value);
}
Inoltre, man mano che le API e le funzionalità DOM vengono aggiunte al service worker, l'elenco dei motivi per creare un documento verrà ampliato o ridotto a seconda dello stato corrente del service worker e dei motivi per utilizzare i documenti offscreen.
Conclusione
I documenti offscreen consentono estensioni che richiedono l'accesso all'interazione con DOM o finestra che attualmente non è possibile ottenere nei service worker. Fornisce inoltre un approccio flessibile, in cui è possibile aggiungere nuovi casi d'uso e rimuovere quelli risolti in futuro. Le estensioni devono utilizzare l'API di documenti offscreen proposta per casi d'uso specifici e il contesto in background principale dell'estensione deve rimanere il service worker specificato nel manifest. Il documento offscreen non deve essere il luogo in cui memorizzare la logica dell'estensione principale perché ha un accesso limitato all'API. La durata di un documento offscreen è indipendente dal service worker che lo ha creato. I casi d'uso e le considerazioni sul lifetime dei worker di servizio nelle estensioni verranno trattati in un post del blog separato. I motivi per utilizzare i documenti offscreen varieranno nel tempo man mano che vengono aggiunte funzionalità e API al servizio worker stesso. Non vediamo l'ora di ricevere il feedback degli sviluppatori man mano che la funzionalità viene implementata.