Runtime 150.0.4078.44 (7 de julho de 2026)

Notas de versão do Microsoft Edge WebView2 Runtime, data de lançamento: 7 de julho de 2026.

O WebView2 Runtime está mudando para uma cadência de lançamento de 2 semanas

A partir da versão 152 (28 de agosto de 2026), o WebView2 Runtime passa para uma cadência de lançamento de 2 semanas. Isso está alinhado com o Microsoft Edge. O WebView2 Runtime versão 151 é a versão final que está em uma cadência de lançamento de 4 semanas.

Consulte [Anúncio] O WebView2 Runtime muda para uma cadência de lançamento de 2 semanas (iniciando a v152).

Correções de bugs

  • Corrigida a reentrância para exclusão de quadros.

  • Correção do acesso ao wrapper de objeto para um Arquivo de Autorização do Usuário (UAF).

  • Carimbada a origem autoritativa do navegador no pipe do host, para evitar uma WebMessageReceivedEventArgs.Source falsificação.

  • Restrito o acesso a um pipe de host singleton, em um WebView2 preterido.

  • Removido o origin parâmetro de métodos que acessam um objeto nativo.

  • Aplicação de host kDeny virtual WebView2 fortalecido contra falsificação de renderizadores e escapes de junção do New Technology File System (NTFS).

  • Corrigida a árvore de Automação da Interface do Usuário (UIA) da janela para visual.

  • Foi corrigida AddScriptToExecuteOnDocumentCreated uma regressão na API.

  • Histogramas de contagem total adicionados para tentativas de criação de controlador e ambiente WebView2.

  • Mapeado TERMINATION_STATUS_LAUNCH_FAILED_OS_POLICY para kLaunchFailed.

  • Atualização da classificação do motivo da falha para OOM, para um processo que foi encerrado para recuperar a memória.

  • Adicionado um snapshot da memória do sistema no momento da detecção de falta de memória (OOM) para análise.

  • Corrigido o fechamento silencioso de um pop-up, quando o host espera que o pop-up permaneça aberto.

  • Adicionada a marca de origem confiável durante o acesso ao objeto host.

  • Pesquisas de mapa redundantes reduzidas no gerenciador de solicitações de URL do WebView2, para melhorar o desempenho.

  • Eliminadas alocações desnecessárias de cadeia de caracteres na camada de cookies WebView2, para melhorar o desempenho.

Alteração interruptiva: Habilitar o suporte de manuscrito do shell do Windows para WebView2 no modo WindowToVisual

O WebView2 está introduzindo suporte para manuscrito do shell do Windows (caligrafia com caneta em texto) para campos de edição dentro de instâncias do WebView2 hospedadas no modo Window to Visual (WindowToVisual) no Windows.

Essa alteração afeta apenas o WindowToVisual modo de hospedagem. WindowToWindow O modo de hospedagem já é compatível com manuscrito do shell do Windows e VisualToVisual o modo de hospedagem não é compatível com essa alteração.

Antes dessa alteração: o WebView2 no WindowToVisual modo não registra um ITfHandwritingSink no thread da TSF (Estrutura de Serviços de Texto). O manuscrito do shell do Windows ainda pode funcionar, mas a determinação do destino do manuscrito usa o caminho baseado em Automação da Interface do Usuário do Sistema Operacional (UIA).

Após esta alteração: Se o sinalizador de msAbydosForWindowlessWV2 recurso estiver desabilitado, o comportamento permanecerá o mesmo de antes dessa alteração, incluindo o caminho de determinação de destino de manuscrito baseado em UIA.

Se o sinalizador de recurso estiver habilitado, o msAbydosForWindowlessWV2 WebView2 no WindowToVisual modo registrará uma por instância ITfHandwritingSink no thread TSF. Isso permite o manuscrito do shell do Windows para editar campos dentro do WebView2 e altera como os eventos de manuscrito TSF são roteados no thread TSF compartilhado.

Se o seu aplicativo já registrar o seu próprio ITfHandwritingSink no thread TSF, o manuscrito com caneta continuará funcionando para os campos de edição nativos do aplicativo e o manuscrito com caneta também funcionará nos campos de edição do WebView2.

Se o seu aplicativo não registrar seu próprio ITfHandwritingSinkmanuscrito, o manuscrito com caneta poderá parar de funcionar nos campos de edição nativos do aplicativo depois que essa alteração for habilitada por padrão. Isso ocorre porque o WebView2 retorna E_NOTIMPL para HWNDs que ele não possui, esperando que o TSF seja encadeado a outro coletor registrado. Se nenhum coletor de host for registrado, o TSF não retornará à resolução de destino de manuscrito baseada em UIA padrão.

Para preservar o suporte de manuscrito com caneta para os campos de edição nativos do seu aplicativo, registre os seus próprios ITfHandwritingSink no thread TSF. O manuscrito com caneta dentro dos campos de edição do WebView2 é habilitado automaticamente por essa alteração.

Você pode validar proativamente o comportamento do seu aplicativo WebView2 ativando o seguinte sinalizador de recurso antes de iniciar seu aplicativo:

set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--enable-features=msAbydosForWindowlessWV2

Nas versões 149 e 150, o sinalizador de recurso é desabilitado msAbydosForWindowlessWV2 por padrão, dando aos aplicativos tempo para testar proativamente. A partir da versão 151, o recurso está planejado para ser habilitado por padrão.

Ao testar seu aplicativo WebView2 com esse sinalizador de recurso habilitado, você pode identificar se algum fluxo de trabalho de manuscrito de campo de edição nativo em seu aplicativo depende do registro de um host ITfHandwritingSink.

Veja também:

Confira também

  • Last updated on