Chrono MockAs páginas web dentro de um aplicativo nativo
Um aplicativo de desktop com um motor web embutido executa suas páginas em um processo separado e isolado. O mecanismo nativo cobre o aplicativo e para nessa fronteira - então a janela vai para a data que você pediu e o painel dentro dela não. Isto fecha essa lacuna.
A falha que parece sucesso
Muitos aplicativos do Windows são nativos por fora e uma página web por dentro. Uma tela de configurações, um painel de controle, uma visualização de relatório, um painel de licença - construídos uma vez em HTML e hospedados em WebView2 ou Qt WebEngine em vez de escritos duas vezes.
O motor executa essas páginas em seu próprio processo, e esse processo é isolado. Uma biblioteca injetada no aplicativo não entra nele. Tudo o que o aplicativo pede ao Windows passa para a data da sessão, e tudo o que a página pede ao JavaScript não:
- A barra de título, os logs e os arquivos dizem 2038.
- O painel dentro da mesma janela diz hoje.
- Nada dá erro, nada avisa, e as duas metades parecem igualmente confiantes.
Essa é a versão cara deste bug, porque o teste parece ter rodado. O comportamento anterior relatava uma sessão assim como um sucesso limpo, o que era uma afirmação que a ferramenta não conseguia sustentar.
O que a sessão faz em vez disso
A sessão executa os dois mecanismos ao mesmo tempo. O hook nativo entra no aplicativo como sempre, e as páginas são alcançadas do único jeito em que se alcança um renderizador isolado: perguntando ao próprio motor.
Na inicialização, o aplicativo herda duas variáveis de ambiente que pedem ao motor dele que abra uma porta de depuração local. Elas são acrescentadas às opções que o aplicativo já passa, em vez de substituí-las. A sessão então observa os próprios processos até que essa porta apareça, e quando ela aparece, cada página e cada worker por trás dela passam para o mesmo relógio do aplicativo.
Um início, uma velocidade, uma linha do tempo. Uma mudança de velocidade ou um salto chega ao aplicativo e às suas páginas juntos, e os temporizadores das páginas correm no ritmo do aplicativo em vez de em um ritmo próprio.
Vem ativado por padrão e se desativa com uma única chave, que não abre porta nenhuma e deixa as páginas no relógio real.
# Nada para configurar - o motor é encontrado se estiver lá chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60 # Ou deixar as páginas em paz e não abrir porta nenhuma chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded
O que o relatório diz sobre as páginas
As páginas não são fundidas nos números do próprio aplicativo. Elas são contadas como unidades próprias, porque um processo e uma página são coisas diferentes e somá-los inventaria um número que não significa nada:
- O cabeçalho conta os dois -
processes: 4, contexts: 1. - Cada página recebe suas próprias linhas, como
context 1: page Date.now (12 calls)na linha de comando e page Date.now - fake clock na tabela de auditoria da janela. - O motor alcançado é nomeado com a porta dele, para que você possa apontar o seu próprio DevTools exatamente para as páginas que a sessão está conduzindo.
Uma execução de teste diz se as páginas seriam alcançadas antes de qualquer coisa ser iniciada. O que os vereditos significam →
Três limites que vale conhecer antes de começar
Uma porta de depuração fica aberta enquanto o motor roda.
Ela escuta apenas neste computador, mas fica aberta para qualquer programa deste computador enquanto o motor estiver rodando, e qualquer coisa que a alcance pode conduzir essas páginas. A sessão avisa toda vez que uma foi aberta, e nomeia a porta em vez de mencioná-la em abstrato. Em uma máquina compartilhada ou não confiável, use a chave que não abre nada.
Um aplicativo executado com privilégios elevados está fora de alcance.
Um motor hospedado por um aplicativo elevado ignora as variáveis que a sessão define, então as páginas dele ficam no relógio real. Essa é a regra do próprio motor, não uma configuração, e não há como contorná-la por fora.
Uma sessão assim relata PARTIAL, e essa é a resposta honesta.
Os processos auxiliares do motor, e as próprias chamadas de tempo nativas do renderizador, ficam no relógio real. As páginas estão no relógio da sessão e o resto dessa família não, então o veredito diz parcial e nomeia o que ficou de fora em vez de arredondar para um sucesso.
Dois menores, ditos com clareza. As páginas leem o fuso da sessão como um deslocamento fixo,
então o Intl o chama pelo deslocamento, como GMT+02:00, e não por
uma cidade. E um temporizador já agendado antes de a sessão alcançar a página
mantém o ritmo antigo, do mesmo jeito que em uma sessão Chromium pura - a sessão avisa em
vez de deixar você concluir que nada aconteceu.
Se o motor é configurado por uma política de argumentos do navegador no registro, a variável da sessão tem precedência durante a execução, e o relatório diz isso - porque uma porta de depuração que você tivesse configurado ali não teria sido aplicada.
Quão bem testado é
Experimental, com o mesmo significado definido do resto daqui: funciona nos alvos para os quais foi construído, não foi testado amplamente, e a auditoria integrada é a sua fonte da verdade, não esta página. Foi medido manualmente em um host WebView2 e em um host Qt WebEngine no Windows de 64 bits, não pela suíte automatizada. Nessas execuções, as páginas leram o ano da sessão no ritmo da sessão e acompanharam um salto.
No Windows de 32 bits há um detalhe que vale conhecer em vez de descobrir: o runtime do WebView2 é de 64 bits mesmo quando o aplicativo que o hospeda é de 32, então uma sessão de 32 bits não consegue nomear os processos do motor nem suas funções. O canal até as páginas continua funcionando. O relatório fica apenas menos específico sobre o que não conseguiu identificar, e diz qual dos dois casos é.