Como o fim do MV2 no Chrome afeta uBlock Origin e seus testes em 31/08/2026

O uBlock Origin “clássico” para Chrome está com o relógio correndo. Segundo o Tecnoblog.net, o fim das extensões baseadas no Manifest V2 (MV2) já tem data: 31 de agosto de 2026. Na minha experiência, isso vai muito além de “parar um bloqueador de anúncios”: é um corte técnico que afeta como o browser permite (ou bloqueia) regras de extensões, e isso muda o comportamento de automações, ferramentas de dev e até setups de privacidade.

O que está acabando: Manifest V2 (MV2) no Chrome e por que isso importa

O Manifest V2 foi, por anos, o “contrato” que definia como extensões interagiam com o Chrome. Quando você instala um bloqueador, ele não só “roda” — ele declara permissões, scripts e filtros em cima dessas regras.

O ponto central aqui é: o Chrome já não queria manter MV2 para sempre. O uBlock Origin chegou a perder compatibilidade oficial em 2024, mas continuou funcionando por algum “suporte residual” a partes do MV2. Agora, com a atualização de documentação apontando para 31/08/2026, o Chrome vai eliminar de vez o rastro do MV2.

O que significa, na prática, “remover MV2 da Chrome Web Store”

Quando o Chrome remove suporte do MV2, acontecem pelo menos três efeitos em cadeia:

Extensões baseadas em MV2 deixam de ser distribuídas na Chrome Web Store (ou seja, você não instala nem atualiza via loja).
Extensões existentes tendem a perder compatibilidade progressivamente conforme os mecanismos do browser deixam de entender certos campos/estados do MV2.
Você pode ficar preso a uma versão antiga (quando ainda roda), sem patch de segurança e sem correções de compatibilidade com mudanças do Chrome.

Segundo a cobertura do Tecnoblog.net, o Chrome 151 é um marco: ele eliminaria de vez o suporte ao MV2. E, ainda que existam exceções para instalações muito antigas, não existe “caminho feliz” para quem depende de update.

Como isso afeta o uBlock Origin (e por que você deve se preocupar mesmo sendo dev)

Eu vejo dois perfis de impacto:

Usuários que só querem o bloqueio funcionando (e vão notar “de repente parou” ou perdeu parte da capacidade).
Dev/Engenheiros que usam extensões para reduzir ruído ao testar UI, automatizar fluxos e depurar comportamento de páginas (inclusive em contextos com CSP, tracking, tags dinâmicas e scripts de terceiros).

Mesmo que você não “use uBlock” para programar, você provavelmente usa alguma extensão que depende do modelo de execução e permissão do MV2. E quando o browser muda o contrato, o comportamento quebra sutilmente: regras deixam de aplicar, eventos não disparam do jeito esperado, e requests começam a vazar.

MV2 vs MV3: a mudança de filosofia do Chrome

O MV3 não é só um “update de versão”. Ele muda o desenho do modelo de extensão e traz restrições (principalmente em torno de como scripts e filtros são executados). O resultado típico é:

Mais controle do browser sobre execução de código e geração de comportamento.
Menos flexibilidade para certos padrões que eram comuns em extensões MV2.

Por isso, mesmo extensões “equivalentes” precisam adaptar seu código. E, quando isso não é feito, o usuário paga a conta na forma de bloqueio parcial ou falhas.

Comparação com alternativas reais: o que você usa quando uBlock MV2 morrer

Na prática, existem três rotas:

Migrar para uma versão MV3 da mesma extensão (se existir).
Trocar de extensão para uma que já esteja no padrão suportado pelo Chrome atual.
Remover dependência e ajustar o workflow (ex.: usar ferramentas de devtools, configurações corporativas, ou filtros no navegador/OS).

Minha recomendação como dev é simples: não trate “bloqueador” como infraestrutura estática. Trate como dependência externa com prazo de validade.

Implicações práticas para quem programa (e para testes automatizados)

Tem implicações que muita gente ignora até quebrar:

Ambiente de QA: se sua automação de testes depende do estado do navegador (extensões instaladas), a mudança do Chrome pode invalidar o baseline.
Depuração de frontend: filtros podem alterar a ordem de carregamento de recursos, mudar XHR/Fetch e afetar timing de componentes (e você “debuga” um phantom bug).
Teste de performance: bloquear trackers muda o volume de requisições e pode melhorar métricas. Se você compara antes/depois sem padronizar extensão, seus números não são comparáveis.
Compliance: em ambientes corporativos, políticas de extensão podem impedir instalar algo que ainda não esteja adequado ao MV3.

Na Prática: como eu preparo meu workflow para não cair em 31/08/2026

Quando eu trato isso como engenharia (não como “toquei aqui e deu”), eu sigo um checklist bem objetivo:

Inventário das extensões do ambiente de trabalho e QA (principalmente as que bloqueiam anúncios/trackers).
Validar o tipo de manifest: se a extensão for MV2, você precisa de plano de migração.
Testar com Chrome atual (ex.: a versão mais próxima do que você espera usar em produção/QA): rode suas páginas críticas e verifique se o bloqueio e o comportamento de UI continuam consistentes.
Congelar dependências: se você usa um navegador “fixo” em containers/VMs, documente a versão e rode um ciclo de revalidação quando o Chrome atualizar.
Repetir o baseline: sempre que mudar o bloqueio, re-capture métricas e revalide fluxos (principalmente autenticação, navegação e pages com conteúdo carregado via JS).

Um exemplo funcional: checando se sua extensão ainda é MV2 (script de apoio)

Se você mantém um repositório com extensões próprias (ou precisa validar pacotes internos), você pode inspecionar o conteúdo do manifest.json dentro do diretório desempacotado. Esse tipo de checagem evita descobrir o problema quando o browser já foi atualizado.

import fs from "node:fs";
import path from "node:path";

function detectManifestVersion(extDir) {
  const manifestPath = path.join(extDir, "manifest.json");
  const raw = fs.readFileSync(manifestPath, "utf8");
  const manifest = JSON.parse(raw);

  if (!manifest.manifest_version) {
    throw new Error(`manifest.json sem manifest_version em: ${extDir}`);
  }
  return manifest.manifest_version;
}

const exts = process.argv.slice(2);

for (const extDir of exts) {
  const mv = detectManifestVersion(extDir);
  console.log(`${extDir} -> manifest_version: ${mv}`);
  if (mv === 2) {
    console.warn("ATENÇÃO: MV2 detectado. Planeje migração para MV3.");
  }
}

Por que esse “porquê” importa? Porque você quer detectar agora, e não no dia em que o Chrome decide parar de interpretar o modelo antigo. Isso reduz risco operacional e evita correria de última hora.

Erros Comuns: o que devs fazem e acabam pagando com tempo e retrabalho

1) Assumir que “extensão vai continuar funcionando para sempre”

Extensão é dependência externa. O Chrome tem ciclos. E MV2 está oficialmente com data marcada para sumir. Quando você não trata como dependência, você trata como surpresa.

2) Não padronizar ambiente entre dev, QA e produção

Quando você compara comportamento em um ambiente com bloqueio ativado versus outro sem, você cria divergência difícil de explicar. Resultado: bugs não reproduzem.

3) Depurar UI ignorando efeitos de bloqueio

Eu já vi isso acontecer: a equipe abre DevTools e “acha que é layout” quando na verdade era request bloqueada. A UI parecia quebrada porque dados nunca chegaram (ou chegaram incompletos).

4) Não registrar versão do Chrome e configuração das extensões

Sem esse registro, você perde rastreabilidade. Em incidentes reais, isso vira investigação por adivinhação.

5) Não preparar alternativa MV3 (ou ficar esperando “alguém resolve”)

Mesmo quando há uma versão MV3 equivalente, pode haver diferença de comportamento. E diferença de comportamento significa que seus testes e validações precisam rodar de novo.

FAQ

1) O uBlock Origin vai parar de funcionar exatamente em 31/08/2026?

O marco de remoção do suporte MV2 citado (conforme Tecnoblog.net) é 31 de agosto de 2026. Na prática, o que você verá pode ser desde perda de recursos até falhas completas, dependendo de como sua versão atual do uBlock e do Chrome estão alinhadas.

2) Se eu já tiver a extensão instalada, ainda vou conseguir atualizar?

Provavelmente não. O ponto levantado na cobertura é que, mesmo que algumas instalações muito antigas funcionem, você deve considerar que não será possível reinstalar ou atualizar via Chrome Web Store quando o MV2 for descontinuado.

3) Trocar de bloqueador é suficiente ou preciso mudar meu workflow de testes?

Na minha visão, precisa mudar o workflow se seus testes dependem do comportamento de bloqueio. Mesmo um “bloqueador equivalente” pode filtrar de forma diferente e afetar timing e requests.

4) MV3 é melhor ou só mais restritivo?

É mais restritivo no modelo de execução e controle do browser. Isso tende a reduzir riscos e melhorar previsibilidade. Mas para quem depende de flexibilidade do MV2, pode exigir mudanças reais na extensão.

5) Como eu descubro se meu ambiente está vulnerável a essa mudança?

Você precisa identificar extensões MV2 instaladas e validar se seus ambientes (dev/QA) foram montados com o mesmo baseline. Um inventário + checagem do manifest.json antes da data resolve 90% do risco.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.