Problemas conhecidos ao migrar para o Manifesto V3

Observação:a descontinuação do Manifest V2 já começou. Confira nossa postagem do blog de maio de 2024 e a página do cronograma de suporte do Manifest V2 para saber mais detalhes.

Recentemente, anunciamos mudanças no cronograma de descontinuação do Manifest V2 e, embora continuemos comprometidos com o Manifesto V3, reconhecemos que há mais trabalho a fazer da nossa parte.

• Antes de anunciar um novo cronograma para a descontinuação, terminamos de abordar as lacunas priorizadas da plataforma e resolvemos os bugs críticos documentados nesta página.
• Demos aos desenvolvedores tempo para criar, garantindo pelo menos seis meses entre o anúncio do cronograma e os experimentos pendentes de remoção do suporte para o Manifest V2.

Eliminação das lacunas na plataforma

Temos o compromisso de eliminar as seguintes lacunas antes de anunciar um novo cronograma de descontinuação do Manifest V2:

Os problemas foram coletados com base no feedback de parceiros, relatórios de bugs e desenvolvedores. Continuaremos o trabalho contínuo para melhorar a estabilidade e o desempenho geral da plataforma de extensões.

No momento, não há problemas em aberto considerados uma lacuna crítica da plataforma.

Os seguintes problemas foram resolvidos recentemente:

1. Suporte para o gerenciamento de arquivos no ChromeOS como substituto do chrome.fileBrowserHandler [Chrome 120].
2. Suporte ao script de usuário:permita o registro de scripts de conteúdo com código arbitrário usando a nova API userScripts [Chrome 120].
3. Mais fortes sinais de atividade do service worker 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 uma solicitação de rede declarativa (DNR, na sigla em inglês). Os conjuntos de regras estáticas ativadas aumentaram de 10 para 50 e o total de conjuntos de regras estáticas aumentaram de 50 para 100 [Chrome 120].
5. Estenda a funcionalidade de documentos fora da tela para oferecer mais motivos para o uso de um documento fora da tela. GEOLOCATION foi adicionado no Chrome 116.
6. Melhoria do suporte para a API chrome.tabCapture [Chrome 116]:
   • Suporte para chamar getMediaStreamId() de um service worker.
   • É possível receber um MediaStream de um ID de stream em um documento fora da tela.
7. Como estender o ciclo de vida do service worker enquanto houver conexões WebSocket ativas [Chrome 116].

Perguntas frequentes sobre o Manifest V3

P: Planejamos oferecer suporte aos service workers persistentes?
R: Um dos principais motivos para migrar de scripts em segundo plano para service workers é o modelo de programação orientada a eventos com maior eficiência de memória, devido à natureza efêmera dos service workers. Consequentemente, não estamos planejando dar suporte aos service workers persistentes. No entanto, para atender às necessidades específicas dos desenvolvedores de extensões, continuamos a fazer muitas melhorias para os service workers. Especificamente, faça o seguinte:

• Todos os eventos de extensão e chamadas de API vão estender o ciclo de vida do service worker.
• Casos de uso selecionados, como mensagens nativas, manterão os service workers ativos por mais de 5 minutos.

P: Existe uma maneira de acessar o DOM em service workers?
R: Seguimos a abordagem da plataforma Web de não incluir o acesso ao DOM em workers da Web, o que inclui service workers. Para dar suporte a casos de uso que exigem acesso ao DOM em segundo plano por service workers, introduzimos a possibilidade de delegar trabalho em segundo plano a documentos fora da tela de curta duração que fornecem acesso total ao DOM.

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

• Suporte para eval() em extensões do DevTools
• Compatibilidade com scripts de usuário.
• Executar código hospedado remotamente em iframes em sandbox
• Arquivos de configuração hospedada remotamente que podem ser interpretados no momento da execução no pacote de extensões. No entanto, os possíveis caminhos de execução precisam ser predeterminados.

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

Esquecemos algo? Avise nossa equipe.