Documentos fora da tela no Manifesto V3

Ian Stanion
Ian Stanion

Para substituir a funcionalidade na transição de páginas em segundo plano para workers de serviço de extensão, os desenvolvedores podem usar a API chrome.offscreen e a permissão de manifesto a partir do Chrome 109. A solicitação dessa permissão permite a criação de documentos fora da tela para usar APIs DOM sem abrir novas janelas ou guias que interrompam a experiência do usuário. A API chrome.offscreen agora está disponível nas extensões do Chrome.

No Chromium, as extensões do Manifest V3 são baseadas em workers de serviço, mas eles não oferecem suporte às mesmas APIs e mecanismos que as páginas baseadas em documentos completos (que incluem páginas de segundo plano e de eventos). Além disso, o uso de scripts de conteúdo para acessar APIs DOM em páginas da Web deixa a extensão à mercê de diferentes políticas de segurança de conteúdo em cada página. Para ajudar a resolver esse problema, estamos lançando os documentos fora da tela para oferecer suporte a recursos e APIs relacionados ao DOM, permitindo que as extensões do Manifest V3 abram documentos fora da tela mínimos, com escopo e relativamente sem permissões no momento de execução usando uma API dedicada.

Informações do recurso

Como os documentos fora da tela foram criados especificamente para processar casos de uso que não têm suporte em service workers (por exemplo, reprodução de áudio), a vida útil dessa página e as permissões concedidas a ela são separadas das do service worker da extensão. A página terá um mecanismo de vida útil semelhante às páginas de eventos no Manifest V2, ou seja, ela será desativada quando parar de realizar ações. Além disso, o user agent pode colocar outras restrições na validade específica para a finalidade especificada. Os documentos fora da tela foram criados para preencher lacunas de APIs que só são acessíveis a APIs DOM. Por isso, as APIs de extensão não precisam ser expostas diretamente nesse contexto. Para reduzir a probabilidade de extensões usarem isso como uma "substituição de página em segundo plano", apenas as APIs de mensagens chrome.runtime são expostas ao documento fora da tela. Os desenvolvedores também podem usar mensagens da Web reivindicando o documento fora da tela como um cliente pelo service worker. Como alguns casos de uso, em particular, o scraping de sites, exigem acesso a frames entre origens, permitimos que esses documentos incorporem frames entre origens seguindo as mesmas regras que as páginas de extensão têm hoje. Em documentos fora da tela, os scripts de conteúdo especificados pela extensão podem ser executados nesses frames para extrair o conteúdo necessário, como em qualquer página da Web normal.

Motivos e exigência de uma finalidade

A criação de um documento fora da tela requer motivos declarados e mais justificativas. Esses motivos estão listados na documentação de referência da API e processam a vida útil do documento de maneiras diferentes. Por exemplo, um documento aberto para reprodução de áudio tem regras diferentes aplicadas ao ciclo de vida do que um documento aberto para gerenciamento da área de transferência. Também é possível adicionar mais detalhes sobre a finalidade do documento fora da tela na justificativa, que é uma string escrita pelo desenvolvedor, e não um parâmetro com efeitos no documento. Com o tempo, mais motivos podem ser adicionados à API à medida que os desenvolvedores compartilham feedback e casos de uso.

Para o futuro

Para facilitar a implementação, a primeira versão dessa API só oferece suporte a uma única página por extensão e perfil por vez. Em versões futuras, podemos relaxar isso para oferecer suporte a várias páginas. No momento, se a extensão estiver em execução no modo dividido com um perfil de navegação anônima ativo, os perfis normais e anônimos poderão ter um documento fora da tela cada. Também está previsto dar a funcionalidade DOM do worker de extensão em um momento posterior. É possível preparar suas extensões para o futuro combinando funções que usam a API fora da tela com uma função comentada equivalente no service worker para troca em uma data posterior.

// 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);
}

Além disso, à medida que a funcionalidade do DOM e as APIs são adicionadas ao service worker, a lista de motivos para criar um documento é adicionada ou reduzida, dependendo do estado atual do service worker e dos motivos para usar documentos fora da tela.

Conclusão

Os documentos fora da tela permitem extensões que exigem acesso de interação com DOM ou janela que não podem ser alcançados em service workers no momento. Ele também oferece uma abordagem flexível, em que novos casos de uso podem ser adicionados e casos de uso resolvidos no futuro podem ser removidos. As extensões precisam usar a API de documento fora da tela proposta para casos de uso específicos, e o contexto de segundo plano principal da extensão precisa permanecer o service worker especificado no manifesto. O documento fora da tela não deve ser o local para armazenar a lógica de extensão principal, porque ele tem acesso limitado à API. A vida útil de um documento fora da tela é independente do service worker que o criou. As considerações sobre o ciclo de vida do service worker e os casos de uso relacionados a ele em extensões serão abordados em uma postagem do blog separada. Os motivos para usar documentos fora da tela vão variar com o tempo, à medida que recursos e APIs forem adicionados ao próprio worker do serviço. Estamos ansiosos para receber o feedback dos desenvolvedores.

Foto de Kari Shea no Unsplash