Problemas conhecidos ao migrar para o Manifesto V3

Esta página documenta as lacunas da plataforma resolvidas durante a transição para o Manifest V3 e responde a perguntas frequentes sobre a migração.

Lacunas resolvidas na plataforma

As seguintes funcionalidades foram adicionadas para resolver bloqueios comuns de migração:

  1. Suporte ao processamento de arquivos no ChromeOS como substituto do chrome.fileBrowserHandler (Chrome 120).
  2. Suporte a scripts de usuário:permite registrar scripts de conteúdo com código arbitrário usando a nova API userScripts (Chrome 120).
  3. Keepalives de service worker fortes adicionais para determinadas operações que levam mais de cinco minutos.
    • Adicionado no Chrome 116 para permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() e management.uninstall().
    • Adicionado no Chrome 118 para chrome.debugger.
  4. Aumente o número de conjuntos de regras estáticos e ativados para a solicitação de rede declarativa (DNR, na sigla em inglês). O número de conjuntos de regras estáticos ativados aumentou de 10 para 50, e o total de conjuntos de regras estáticos aumentou de 50 para 100 (Chrome 120).
  5. Estender a funcionalidade Documento fora da tela para oferecer suporte a mais motivos para usar um documento fora da tela. Adição do GEOLOCATION no Chrome 116.
  6. Melhoria no suporte à API chrome.tabCapture (Chrome 116):
    • Suporte para chamar getMediaStreamId() de um service worker.
    • Suporte para obtenção de um MediaStream de um ID de fluxo em um documento fora da tela.
  7. Extensão do ciclo de vida do service worker enquanto há WebSocket conexões ativas (Chrome 116).

Perguntas frequentes sobre o manifesto V3

P: Pretendemos oferecer suporte a service workers persistentes?
R:Um dos principais motivos para migrar de scripts em segundo plano para service workers é o modelo de programação orientado a eventos mais eficiente em termos de memória, que vem da natureza efêmera dos service workers. Por isso, não planejamos oferecer suporte a service workers persistentes. No entanto, para atender às necessidades específicas dos desenvolvedores de extensões, continuamos fazendo muitas melhorias nos service workers. Especificamente:

  • Todos os eventos de extensão e chamadas de API vão estender o ciclo de vida do service worker.
  • Alguns casos de uso selecionados, como mensagens nativas, mantêm os service workers de extensões ativos por mais de 5 minutos.

P: Existe uma maneira de acessar o DOM em service workers?
R:Seguimos a abordagem da plataforma da Web de não incluir acesso ao DOM em Web Workers (que incluem service workers). Para oferecer suporte a casos de uso que exigem acesso ao DOM em segundo plano de service workers, introduzimos a possibilidade de delegar o trabalho em segundo plano a documentos offscreen de curta duração, que oferecem acesso total ao DOM.

P: Haverá uma maneira de oferecer suporte a código remoto no Manifest V3?
R:Para tornar as extensões do Chrome mais seguras, vamos continuar proibindo a execução de código arbitrário hospedado remotamente nelas. No entanto, isso não significa que proibimos todos os tipos de execução de código dinâmica. Ainda oferecemos suporte a diferentes opções de execução dinâmica de código em extensões do Chrome:

P: Minha extensão do Manifest V2 depende do webRequestBlocking, que não é compatível com o Manifest V3. Como posso continuar oferecendo a mesma funcionalidade no Manifest V3?
R:Acreditamos que a maioria dos casos de uso de bloqueio de solicitações pode ser resolvida com a nova API declarativeNetRequest, que tem o benefício adicional de evitar a sobrecarga de desempenho da comunicação entre processos, a execução de código em cada solicitação ou a necessidade de um processo de extensão ativo no momento da solicitação. No entanto, para casos de uso empresariais (ou educacionais) complexos, o bloqueio dinâmico de solicitações ainda é compatível.

O que a gente deixou passar? Entre em contato com nossa equipe.