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 位元工作階段無法指出引擎的處理序或它們的角色。通往頁面的通道仍然有效。只是報告對於無法辨識的部分會不那麼具體，並會說明是兩種情況中的哪一種。