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 service workers de extensão, os desenvolvedores podem usar a API chrome.offscreen e a permissão de manifesto a partir do Chrome 109. Solicitar essa permissão permite a criação de documentos fora da tela para usar APIs do DOM sem abrir intrusivamente novas janelas ou guias que interrompem 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 service workers, mas os service workers não oferecem suporte aos mesmos mecanismos e APIs que as páginas baseadas em documentos completas (que incluem páginas de eventos e plano de fundo). Além disso, o uso de scripts de conteúdo para acessar APIs DOM em páginas da Web deixa a extensão sob a mercê de diferentes políticas de segurança de conteúdo de página a página. Para ajudar a resolver isso, estamos lançando 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 não autorizados no tempo de execução por meio de uma API dedicada.

Informações do recurso

Como os documentos fora da tela são projetados especificamente para lidar com casos de uso sem suporte em service workers (por exemplo, reprodução de áudio), o ciclo de vida desta página e as permissões que serão concedidas são separados daqueles do service worker de extensão. A página terá um mecanismo de ciclo de vida semelhante às páginas de evento no Manifest V2, em que será removida quando parar de realizar ações. Além disso, o user agent pode impor mais restrições ao ciclo de vida específico para a finalidade especificada. Os documentos fora da tela foram criados para preencher as lacunas das APIs que só são acessíveis às APIs do DOM. Por isso, as APIs de extensão não precisam ser expostas diretamente nesse contexto. Para reduzir a probabilidade de as extensões usarem essas configurações como uma "substituição de página de plano de fundo", somente 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 por meio do service worker. Como alguns casos de uso, em especial a captura de site, exigem acesso a frames de origem cruzada, permitimos que esses documentos incorporem frames de origem cruzada seguindo as mesmas regras atuais das páginas de extensão. Em documentos fora da tela, os scripts de conteúdo especificados pela extensão podem ser executados nesses frames para raspar todo conteúdo necessário, como fariam em qualquer página da Web normal.

Motivos e necessidade de um propósito

A criação de um documento fora da tela exige motivos declarados e outras justificativas. Esses motivos estão listados na documentação de referência da API e lidam com a vida útil do documento de maneiras diferentes. Por exemplo, no momento, um documento aberto para reprodução de áudio tem regras diferentes aplicadas ao seu ciclo de vida em comparação a 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. Outros motivos poderão ser adicionados à API com o tempo, à medida que os desenvolvedores compartilharem feedbacks e casos de uso.

Para o futuro

Para facilitar a implementação, a primeira versão dessa API suporta apenas uma única página por extensão, por perfil. Em versões futuras, isso poderá ser flexibilizado para oferecer suporte a várias páginas. No momento, se a extensão estiver sendo executada no modo de divisão com um perfil de navegação anônima ativo, os perfis normal e anônimo poderão ter um documento fora da tela. Também planejamos fornecer a funcionalidade DOM de worker de extensão mais tarde. É possível preparar suas extensões para o futuro pareando 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 e as APIs DOM são adicionadas ao service worker, a lista de motivos para criar um documento será 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 à interação com a janela ou DOM que não podem ser alcançados em service workers atualmente. Ela 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 empregar a API de documento fora da tela proposta para casos de uso específicos, e o contexto principal em segundo plano da extensão deve 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 tem acesso limitado à API. O ciclo de vida 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 ao ciclo de vida do service worker em extensões serão abordados em outra postagem do blog. Os motivos para usar documentos fora da tela variam com o tempo, à medida que recursos e APIs são adicionados ao próprio service worker. Estamos ansiosos para receber o feedback dos desenvolvedores à medida que isso acontece.

Foto de Kari Shea no Unsplash