Chrono Mock原生应用里的网页
内置了网页引擎的桌面应用，会在一个独立的沙盒进程中运行它的页面。原生机制覆盖了应用本身，却止步于这道边界——于是窗口跳到了你指定的日期，而窗口里的面板没有。这里补上的就是这个缺口。
看起来像成功的失败
很多 Windows 应用外面是原生的，里面却是一个网页。设置界面、仪表盘、报表视图、许可证面板——用 HTML 做一次，托管在 WebView2 或 Qt WebEngine 中，而不是写两遍。
引擎在它自己的进程中运行这些页面，而那个进程是沙盒化的。注入到应用里的库进不去。应用向 Windows 询问的一切都会移到会话的日期，页面向 JavaScript 询问的一切则不会：
- 标题栏、日志和文件上写的是 2038。
- 同一个窗口里的面板写的是今天。
- 没有报错，没有警告，两半看上去同样笃定。
这就是这类缺陷代价高昂的版本，因为测试看起来已经跑过了。较早的行为会把这样的会话报告为干净的通过，而这是工具无法担保的说法。
会话改为这样做
会话同时运行两种机制。原生钩子照常进入应用，而页面则通过任何东西进入沙盒渲染进程的唯一途径到达：直接请求引擎本身。
启动时，应用会继承两个环境变量，要求它的引擎打开一个本地调试端口。它们被追加到应用本来就传入的所有开关之后，而不是替换它们。随后会话监视自己的进程，等待该端口出现，一旦出现，它背后的每一个页面和每一个 worker 都会与应用处于同一个时钟上。
一个起点，一种速度，一条时间线。速度变化或跳转会同时作用于应用及其页面，页面中的定时器以应用自己的节奏运行，而不是各走各的。
它默认开启，用一个开关即可关闭，关闭后完全不会打开端口，页面保持使用真实时钟。
# 无需配置——只要引擎存在就会被找到 chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60 # 或者不去动这些页面，也不打开任何端口 chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded
报告对这些页面是怎么说的
页面不会被并入应用自己的数字。它们作为独立的单位来计数，因为进程和页面是两回事，把它们相加会凭空造出一个毫无意义的数字：
- 总览同时统计两者——
processes: 4, contexts: 1。 - 每个页面都有自己的行，例如命令行中的
context 1: page Date.now (12 calls)，以及窗口审计表中的 page Date.now - fake clock。 - 被连接到的引擎会连同端口一起写明，这样你可以让自己的 DevTools 精确地指向会话正在驱动的那些页面。
试运行会在启动任何东西之前告诉你页面是否会被连接到。 判定结果的含义 →
开始之前值得了解的三个限制
引擎运行期间，会有一个调试端口保持开放。
它只在这台计算机上监听，但在引擎运行期间，这台计算机上的任何程序都可以访问它，能够连上它的任何东西都可以驱动这些页面。每当打开了这样的端口，会话都会发出警告，并写明具体的端口，而不是泛泛地提一句。在共享或不受信任的机器上，请使用什么都不打开的那个开关。
以管理员权限运行的应用无法触及。
由以管理员权限运行的应用所托管的引擎，会忽略会话设置的这些变量，所以它的页面仍然使用真实时钟。这是引擎自己的规则，而不是某项设置，从外部没有办法绕过。
这样的会话会报告 PARTIAL，这是诚实的答案。
引擎的辅助进程，以及渲染进程自己的原生时间调用，仍然使用真实时钟。页面在会话时钟上，而这一族进程的其余部分不在，所以判定会写部分生效并点明遗漏了什么，而不是向上取整成通过。
还有两个较小的限制，直说如下。页面读取的是作为固定偏移的会话时区，所以 Intl 把它称为 GMT+02:00 这样的偏移，而不是城市。而在会话到达页面之前就已经排定的定时器会保持原来的速率，这与纯 Chromium 会话中的情况相同——会话会发出警告，而不是让你得出什么都没发生的结论。
如果引擎是通过注册表中的浏览器参数策略来配置的，那么在会话期间，会话设置的变量优先，报告会如实说明这一点——因为你在那里设置的调试端口不会被应用。
测试得如何
实验性，含义与本站其他地方相同：它在当初开发时针对的目标上可以工作，尚未经过广泛测试，而内置的审计才是你的事实依据，而不是本页面。它是由人工针对 64 位 Windows 上的一个 WebView2 宿主和一个 Qt WebEngine 宿主测量的，而不是由自动化测试套件完成的。在这些运行中，页面按会话的速率读到了会话的年份，并且跟随了一次跳转。
在 32 位 Windows 上有一个值得提前了解、而不是事后才发现的小麻烦：即使托管它的应用是 32 位的，WebView2 运行时也是 64 位的，所以 32 位会话无法指出引擎的进程或它们的角色。通向页面的通道仍然有效。只是报告对于无法识别的部分会不那么具体，并会说明是两种情况中的哪一种。