Chrono Mock

The web pages inside a native app

A desktop application with a built-in web engine runs its pages in a separate, sandboxed process. The native mechanism covers the application and stops at that boundary - so the window moves to the date you asked for and the panel inside it does not. This closes that gap.

The failure that looks like a success

Plenty of Windows applications are native on the outside and a web page on the inside. A settings screen, a dashboard, a report view, a licence panel - built once as HTML and hosted in WebView2 or Qt WebEngine rather than written twice.

The engine runs those pages in its own process, and that process is sandboxed. A library injected into the application does not get into it. Everything the application asks Windows for moves to the session's date, and everything the page asks JavaScript for does not:

  • The title bar, the logs and the files say 2038.
  • The panel inside the same window says today.
  • Nothing errors, nothing warns, and both halves look equally confident.

That is the expensive version of this bug, because the test appears to have run. The older behaviour reported such a session as a clean pass, which was a claim the tool could not back.

What the session does instead

The session runs both mechanisms at once. The native hook goes into the application as always, and the pages are reached the only way anything reaches a sandboxed renderer: by asking the engine itself.

At launch the application inherits two environment variables that ask its engine to open a local debugging port. They are appended to whatever switches the application already passes rather than replacing them. The session then watches its own processes for that port to appear, and when it does, every page and every worker behind it goes onto the same clock as the application.

One start, one speed, one timeline. A speed change or a jump reaches the application and its pages together, and the pages' timers run at the application's own pace rather than a pace of their own.

It is on by default and off with one switch, which opens no port at all and leaves the pages on the real clock. 

# Nothing to configure - the engine is found if it is there
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

# Or leave the pages alone, and open no port
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded

What the report says about the pages

The pages are not folded into the application's own numbers. They are counted as units of their own, because a process and a page are different things and summing them would invent a number that means nothing:

  • The headline counts both - processes: 4, contexts: 1.
  • Each page gets its own rows, such as context 1: page Date.now (12 calls) on the command line and page Date.now - fake clock in the window's audit table.
  • The engine that was reached is named with its port, so you can point your own DevTools at exactly the pages the session is driving.

A dry run says whether the pages would be reached before anything is started. What the verdicts mean →

Three limits worth knowing before you start

A debugging port stands open while the engine runs.

It listens on this computer only, but it is open to any program on this computer for as long as the engine is running, and anything that can reach it can drive those pages. The session warns about it every single time one was opened, and names the port rather than mentioning it in the abstract. On a shared or untrusted machine, use the switch that opens nothing.

An application running elevated is out of reach.

An engine hosted by an elevated application ignores the variables the session sets, so its pages stay on the real clock. This is the engine's own rule, not a setting, and there is no way around it from outside.

Such a session reports PARTIAL, and that is the honest answer.

The engine's helper processes, and the renderer's own native time calls, stay on the real clock. The pages are on the session clock and the rest of that family is not, so the verdict says partial and names what was left out rather than rounding up to a pass.

Two smaller ones, said plainly. The pages keep this machine's time zone, so an independent session zone is a native-mode feature only. And a timer already scheduled before the session reached the page keeps its old rate, the same way it does in a pure Chromium session - the session warns rather than letting you conclude nothing happened.

If the engine is configured through a browser-arguments policy in the registry, the session's variable takes precedence for its duration, and the report says so - because a debugging port you set up there would not have been applied.

How well tested is it

Experimental, with the same defined meaning as elsewhere here: it works on the targets it was built against, it has not been tested broadly, and the built-in audit is your source of truth rather than this page. It was measured by hand against a WebView2 host and a Qt WebEngine host on 64-bit Windows, not by the automated suite. In those runs the pages read the session's year at the session's rate and followed a jump.

On 32-bit Windows there is a wrinkle worth knowing rather than discovering: the WebView2 runtime is 64-bit even when the application hosting it is 32-bit, so a 32-bit session cannot name the engine's processes or their roles. The channel to the pages still works. The report is simply less specific about what it could not identify, and says which of the two it is.

Try it

Download for Windows Read the FAQ