jint Documentation

Technical Documentation: sebastienros/jint

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

Jint

Jint is a modern ECMAScript interpreter for .NET. It runs JavaScript directly in
your process without native dependencies, bytecode generation, or a separate
runtime.

Jint targets .NET Framework 4.7.2, .NET Standard 2.0/2.1, .NET 8, and .NET 10.
Start with the documentation or install
the core package:

dotnet add package Jint

Quick start Copy Chapter

The examples below assume using Jint;.

Evaluate JavaScript Copy Section

var engine = new Engine();
var result = engine.Evaluate("40 + 2").AsNumber();

Expose .NET and call JavaScript Copy Section

var engine = new Engine()
    .SetValue("log", new Action<string>(Console.WriteLine))
    .Execute("""
        function greet(name) {
            const message = `Hello, ${name}!`;
            log(message);
            return message;
        }
        """);

var greeting = engine.Invoke("greet", "Ada").AsString();

Prepare code that runs repeatedly Copy Section

var script = Engine.PrepareScript(
    "items.reduce((sum, value) => sum + value, 0)",
    source: "sum.js",
    strict: true);

var engine = new Engine();
engine.SetValue("items", new[] { 1, 2, 3 });

var total = engine.Evaluate(in script).AsNumber();

Prepared<Script> and Prepared<Module> are thread-safe and may be shared
across engines. JavaScript objects are not: a JsValue that contains an object
belongs to the engine and realm that created it.

Features Copy Chapter

• Modern ECMAScript, modules, promises, async functions, generators, Intl,
  and Temporal
• Direct projection of .NET values, delegates, objects, collections, and types
• Synchronous and asynchronous module loaders
• Execution constraints, hardened untrusted-code defaults, and security
  diagnostics
• Profiling, statement coverage, debugging, and Chrome DevTools Protocol
  integration
• Opt-in Web APIs and Node-compatible modules
• A headless browser, command-line tool, and MCP server

Browser and Node APIs are not installed by default. Hosts explicitly grant the
capabilities each script needs.

Used by Copy Chapter

Projects using Jint include
RavenDB,
EventStoreDB,
Orchard Core,
Elsa Workflows,
Docfx, and
JavaScript Engine Switcher.

Additional packages Copy Chapter

Jint is the core package used throughout this README. Add another package
only when the application needs an optional debugging or browser surface.

See Additional packages
for dependencies, target frameworks, and common combinations.

Branches and releases Copy Chapter

Jint 5 is under development on main and has not been released. This branch
includes breaking changes; development packages are available from the
preview feed.

The 4.x branch is the maintenance lane for Jint 4.16. Changes there preserve
compatibility and focus on non-breaking correctness and conformance fixes. The
3.x branch receives only security and severe-correctness maintenance.

Pull requests target main unless they are explicit backports. See
Branches and Releases
for the complete policy and
Migrating to Jint 5
when upgrading from Jint 4.

Standards conformance Copy Chapter

These percentages describe the pinned test corpora in this repository, not the
entire web platform.

The test262 result uses commit
419d3e0.
Read the detailed scope and exclusions for
ECMAScript,
Web APIs, and
Jint.Browser.

Recommended usage Copy Chapter

• Enable strict mode when compatible with the scripts you run.
• Prepare and cache scripts or modules that execute repeatedly.
• Give each engine to only one operation at a time; await async operations
  before reusing or disposing it.
• Expose narrow, purpose-built host capabilities instead of broad CLR access.
• Use a fresh engine across trust domains. Global snapshots help trusted reuse,
  but they are not an isolation boundary.
• Measure with your own scripts and host objects. Interpreter performance
  depends heavily on call frequency and script-to-host traffic.

See performance
and advanced hosting
for engine lifetime, pooling, projection, and caching guidance.

Benchmarks Copy Chapter

The repository's current default-job BenchmarkDotNet comparison uses each
engine's recommended cached execution path:

• Jint is the fastest managed engine on 10 of 12 scripts and the fastest
  interpreter on all 12.
• Jint has the lowest managed allocation on 10 of 12 scripts.
• Script-to-host interop is 3.4x to 11.2x faster than the measured ClearScript
  lanes.
• The startup-shaped minimal script runs in about 1.1 us with a prepared Jint
  script, compared with about 380 us for the compiled V8 lane.

Native V8 remains faster on long, compute-heavy loops. Managed allocation
figures also cannot include V8's native heap. Read the
engine comparison and methodology
before comparing engines; absolute numbers from different benchmark sessions
are not comparable.

Running untrusted code Copy Chapter

Jint is an in-process interpreter, not an operating-system security boundary.
Start with the hardened profile, keep the host surface small, and add a
process-level boundary for hostile input.

var limits = UntrustedCodeLimits.Default with
{
    TimeoutInterval = TimeSpan.FromSeconds(1),
    MaxStatements = 50_000,
    MemoryLimit = 16_000_000
};

var options = new Options().ForUntrustedCode(limits);
using var engine = new Engine(options);

using (limits.BeginOperation(engine, cancellationToken))
{
    var value = engine.Evaluate(source);
    return engine.ConvertResult(value, limits.ResultLimits);
}

The profile disables broad CLR and reflection access, module loading, string
compilation, projected CLR writes, live CLR-array views, registered extension
methods, and blocking Atomics.wait. It also applies finite parsing, execution,
memory, recursion, regular-expression, promise, and result limits.

Constraints are cooperative and cannot preempt arbitrary host callbacks. Use
an external deadline, restrict module and network loaders on every hop, and run
hostile code in a least-privileged disposable process or container.

Read Running untrusted code
and the threat model
before deploying a script service.

Documentation and support Copy Chapter

• Documentation
• Preview packages
• Migration to Jint 5
• Issues
• Sponsors

Jint is licensed under the BSD 2-Clause License.

Overview (`Jint.Benchmark/README.md`) Copy Section

Engine comparison benchmarks

This project benchmarks Jint against the other JavaScript engines available to .NET applications:
the managed engines (NiL.JS,
Okojo and YantraJS) and
ClearScript — Microsoft-originated, now
ClearFoundry-maintained bindings to Google's native V8 engine (the JIT inside Chrome and Node.js) —
across a set of representative scripts.

Most of this document is about that cross-engine comparison. The rest of the project is Jint-only
micro-benchmarks, which need no prose beyond their own XML doc comments — with one exception:
the opt-in WHATWG web APIs have their own category, their own smoke mode and their own rules about
what to run when. That is Web API rows, at the end.

How each engine executes Copy Chapter

The engines reach the result in different ways, which shapes the numbers below:

• Jint — tree-walking interpreter over a prepared AST.
• NiL.JS — interpreter (with an optimizing pass over its syntax tree).
• Okojo — interpreter that compiles the script to bytecode and runs it on a virtual machine.
• YantraJS — compiler: it emits .NET IL, which the CLR then JIT-compiles to native code.
• ClearScript (V8) — native V8 behind a managed ↔ native interop bridge: a multi-tier
  optimizing JIT running outside the CLR, with every host interaction crossing the native boundary.

The structural consequences shape the whole table. Only the two compilers (YantraJS and V8) run
ahead on long, tight numeric/call loops, where compiled code approaches native speed. The
interpreters own the other end of the trade: engine start-up and small scripts, where even a
context created from a pre-warmed V8 isolate costs ~375 µs for work Jint completes in about a
microsecond. And pure-JS compute is only half of an embedding story — the other half is the
script ↔ host boundary, measured separately in the
interop section below, where the price of V8's native boundary inverts
the picture.

The scripts Copy Chapter

One variant per workload, 12 scripts in total. Where the suite previously carried both a classic
ES5 script and an ES2015+ -modern rewrite of it, only the modern variant is kept — that is how
JavaScript is written today, and the duplicated rows ranked the engines nearly identically while
doubling the wall-clock time of a full run. (The classic scripts remain in Scripts/ and are still
used by the Jint-only benchmarks.)

Running the benchmarks Copy Chapter

Run from this directory (the scripts are loaded relative to the working directory):

dotnet run -c Release -- --allCategories EngineComparison

Notes:

• The -- separator is required so the arguments are forwarded to BenchmarkDotNet instead of being
  consumed by dotnet run.
• --allCategories EngineComparison runs both the script suite and the interop suite; use
  --allCategories EngineComparisonInterop for the interop suite alone, or
  --filter "*EngineComparisonBenchmark*" for the script suite alone.
• Results are written to BenchmarkDotNet.Artifacts/results/ — the
  *-report-github.md file is the table reproduced below.
• To re-measure a single engine (e.g. after a package bump) without disturbing the rest of the
  table, filter to its lane, for example --filter "*EngineComparisonBenchmark.Okojo*".
• The benchmark config widens the parameter column (MaxParameterColumnWidth = 40) so the full
  script names are printed instead of BenchmarkDotNet's default truncation (e.g.
  dromaeo-object-string-modern rather than droma(...)odern [28]).

How to read the table Copy Chapter

• All engines are run in global strict mode — YantraJS is strict-only, and Okojo and
  ClearScript have no engine-level strict switch, so their source carries a leading "use strict"
  directive. Strict mode improves performance across the board.
• Every operation uses a fresh engine — the embedding pattern where executions must not leak
  state into each other.
• Three engines have a cached-artifact lane next to the re-parse lane, and the pairs mean the
  same thing: Jint_ParsedScript reuses a Prepared<Script> produced once by
  Engine.PrepareScript; Okojo_Prepared reuses a parsed program (Okojo's realm-independent
  artifact) and re-compiles the bytecode against each run's fresh realm; ClearScript_Compiled
  reuses a V8Script compiled once by a shared V8Runtime and runs it in a fresh script engine (a
  fresh V8 context) created from that runtime. The gap to the re-parse lane is parsing/compilation
  cost — in production you should cache the prepared artifact, which is what these lanes
  represent.
• The plain ClearScript lane creates a full V8 isolate + context per operation — the honest cost
  when each request gets a fully isolated engine, and the reason its short-script rows start around
  a millisecond. ClearScript_Compiled shares one isolate (and its warmed JIT state) across
  operations while still using a fresh context per operation — ClearScript's recommended production
  path.
• Allocated counts managed memory only. ClearScript's working memory lives on V8's native
  heap, which the managed diagnoser cannot see — the few dozen KB in its rows are interop-bridge
  overhead, not a memory-use figure comparable with the managed engines. Memory claims in this
  document therefore compare the managed engines with each other.
• V8 runs background threads (tiered JIT compilation, garbage collection). Mean is the wall-clock
  time the executing thread observes; total CPU consumed is higher than for the single-threaded
  managed engines, which matters on saturated servers.
• Mean is time per operation (lower is better); Rank groups results that are statistically
  tied. Every lane in both tables below comes from a single benchmark session on one machine, so
  ranks are BenchmarkDotNet's own — no rows are merged from separate runs. Cross-session
  comparisons of absolute numbers (including the V8 lanes) are unreliable; compare within a table.
• The dromaeo-object-regexp-modern row is the highest-variance in the table (for Jint it is
  dominated by .NET Regex); treat small gaps there — including ClearScript's fresh-engine lane
  appearing ahead of its compiled lane, and Jint's own two lanes sitting ~12% apart — as
  run-to-run noise. Jint's lead on that row is not one of those: the prepared lane is ~18 ms clear
  of the nearest V8 lane, more than five times its own standard deviation.

At a glance Copy Chapter

Using each engine's recommended production path (for Jint a cached prepared script,
Jint_ParsedScript; for ClearScript a precompiled V8Script on a shared runtime,
ClearScript_Compiled):

• Jint owns everything start-up-shaped and eval-shaped; native V8 owns long compute. Jint is
  the fastest engine outright on minimal (1.1 µs vs V8's 380 µs, ~345×), evaluation-modern
  (~80×), linq-js (~6.7×), dromaeo-core-eval-modern (~5% ahead of V8's compiled
  lane — eval defeats its compile cache) and dromaeo-object-regexp-modern (1.25× ahead of V8's
  fresh-context lane and 1.46× ahead of its compiled lane). That is five rows outright, out of
  twelve. No other managed engine takes a single row's top rank away from Jint or V8.
• V8's wins are the tight-loop compute rows: dromaeo-string-base64-modern (9.8×),
  dromaeo-object-string-modern (6.6×), stopwatch-modern (6.0×), dromaeo-3d-cube-modern
  (3.4×), json-parse-modern (2.2×) and narrow leads on array-stress (1.09×) and
  dromaeo-object-array-modern (1.08×) — the structural interpreter-vs-JIT gap. The two string
  rows carry the widest spread between Jint's own two lanes in this table (5% on base64, 10% on
  object-string, for lanes that differ only in whether the script was re-parsed), so read those
  two multipliers as approximate.
• Jint is the fastest managed engine on 10 of 12 scripts (the IL-compiling YantraJS leads
  dromaeo-3d-cube-modern and stopwatch-modern) and the fastest interpreter on all 12.
• Jint allocates the least of the managed engines on 10 of 12 scripts — Okojo is lower on
  dromaeo-object-array-modern (6,985 vs 9,122 KB) and NiL.JS on minimal (4.5 vs 9.9 KB).
  NiL.JS and YantraJS allocate one to two orders of magnitude more on the heavy rows, up to
  ~469× more than Jint on dromaeo-string-base64-modern (763,918 vs 1,628 KB), which means
  far heavier GC pressure in real applications. (ClearScript's rows cannot be compared here — its
  memory lives on the V8 native heap, which the managed diagnoser does not see.)
• Pure-JS compute is only half the story — the interop suite below
  measures the script ↔ host boundary, where the picture inverts and Jint beats ClearScript on
  every row by 3.4×–11.2×.

What changed since the 4.13.0 table Copy Section

A profile-guided campaign (PRs #2716–
#2722) attacked the rows where V8 led, measured
with same-base A/B gates: string-receiver method calls are cached per call site
(dromaeo-object-string-modern −20%, -base64-modern −17%), JSON.parse interns property keys
(bestbuy-style payloads −22% and −32% allocation), chained slice() no longer materializes
intermediate views (−99.3% on that pattern), interop argument binding lost its per-call
reflection checks and boxing, ObjectWrapper members gained a per-callsite inline cache
(interop-property-access −25%), and CLR arrays gained identity caching plus an opt-in
ArrayConversionMode.LiveView mode (array traversal 2.5× faster, −75% allocation, without flags).

A second campaign round (PRs #2725,
#2726) added bulk JSON string scanning plus an
exactly-rounded simple-number fast path (JsonBenchmark Parse −15–17%) and memoized closure-read
chain validation (dromaeo-string-base64-modern −6% at launchCount-5). A third candidate —
arity-specialized direct dispatch for built-in calls, eliminating the argument array — was built,
proven to engage on 4.3M of 4.3M eligible calls, and measured flat: Jint's builtin-call path
(pooled argument arrays + the cached-callee lane) is already at its cost floor, so the remaining
gap on the string rows is interpreter dispatch itself, not call ceremony. Measured-and-dropped is
recorded here so it isn't re-attempted.

The 4.14.0 release round shipped the two interop default flips — CLR arrays cross as live views
(#2728) and recently wrapped objects reuse their
wrappers (#2734) — backed by cached array-like
wrapper factories with lazy length (#2730),
boxing-free primitive element conversion (#2731,
extended to the Array.prototype iteration lane in
#2735), a compiled-invoker fast lane for
single-candidate interop calls (#2733) and
JSON.parse value interning plus span-based number parsing
(#2732). The visible movement in this table:
interop-collection-traversal 15,597 → 1,433 µs (10.9×, −99% allocation) without any script
changes, every other interop row −8–16% with −17–76% allocation, json-parse-modern −6% time and
−23% allocation, and stopwatch-modern −6%. A pre-release review wave
(#2735–#2740)
hardened the new defaults (declared-type contracts, JS-array in/enumeration/out-of-range
semantics, constraint-gate balance) with no measurable cost; one further candidate — carrying the
interned JSON key hash into member adds — measured flat and was dropped.

Since 4.14.0, a further interop round cached the compiled method invoker process-wide instead of
per-engine (#2743), compiled CLR property and
field access instead of reflecting on every hit (#2744,
which also more than halved interop-property-access allocation, 798 → 329 KB), trimmed the method
fast lane's per-call overhead (#2745), and
memoized the converted value of a stable reference-typed property so a host array read in a loop
skips re-conversion (#2756). The visible movement
in the interop table: interop-collection-traversal and interop-string-passing now rank first
(collection −8% from the memo alone, ahead of NiL.JS), and method calls closed to within ~4% of
NiL.JS while still allocating 7× less.

What changed for 4.15.0 Copy Section

The 4.15.0 round shipped a string and regexp allocation wave — vectorized special-casing and
search pre-scans (#2775,
#2776), toWellFormed no longer rebuilding
already-well-formed strings (#2778), dense fast
paths for the callback-free array methods (#2779,
#2780) and the string-concat plus RegExp fixes
aimed at this suite's regexp row (#2781, with
follow-up concat correctness in #2811 and
#2812) — a fast-call lane for built-in calls
with declared per-argument leaf guards
(#2783,
#2828,
#2844), span- and UTF-8-based JSON parsing
(#2832), and an interop round that compiles CLR
member access for keyed writes, indexers and statics
(#2839), shares resolved members process-wide
across engines (#2798) and stops re-reflecting
on every host delegate call (#2799).

The visible movement in these tables: dromaeo-object-regexp-modern
123,563 → 71,625 µs (−42%) with −47% allocation (157,850 → 82,980 KB), which takes the row
from rank 3 to rank 1 — ahead of both V8 lanes, and the first time Jint leads it;
dromaeo-object-string-modern −21%; dromaeo-string-base64-modern −13% on the prepared
lane (the re-parse lane's −30% is partly the previous session's high reading — the two Jint lanes
now agree to within 1%); array-stress −5%, back to a rank-1 tie with V8's compiled lane;
json-parse-modern −1% time with −4% allocation. On the interop side interop-property-access is
−11% and interop-method-calls −4%, while interop-collection-traversal moved the other way
(+5%) and NiL.JS retook that row by ~4%.

What changed for 4.16.0 Copy Section

The headline of the 4.16.0 round is proper tail calls for strict functions
(#2975): tail-position analysis plus a trampoline
that dispatches an interpreted tail call without growing the execution-context or call stacks,
with cleanup, constructor, callback, debugger and recursion-limit semantics preserved. In Jint's
own script benchmarks — not this comparison suite — the controlflow-recursive row measured
−15.6% time and −40.4% allocation against 4.15.3. Here it lands wherever a script recurses in
tail position rather than on any single row.

The fast-call lane — built-in calls that skip the pooled argument array and, where every route to
user code is closed off by a checkable guard, the call frame as well — grew again:
parseInt/parseFloat became one realm intrinsic each and took the frameless lane
(#2968); the cheapest Number type tests and six
String.prototype search methods followed under declared per-argument guards
(#2980); and Map/Set lookups became frameless
once each instance carried a type bit the guard could check
(#2984). On the interop side a wrapped dictionary
now answers existence questions — in, hasOwnProperty, for..in, Object.keys, spread,
JSON.stringify — from the target's compiled ContainsKey instead of converting the value and
building a descriptor only to discard both
(#2969); no script in the interop suite
enumerates a host dictionary, so that one does not surface in the table below.

One correctness fix went the other way, and its cost is disclosed rather than absorbed quietly:
Array.prototype.join (and toString, which is defined as a call to it) now re-reads a hole
through the array instead of answering undefined from its snapshot, because a toString side
effect on an earlier element can add an index property to the prototype that every later element
has to see (#3003). The packed path is untouched;
a hole-heavy join costs +3.4%.

Against the 4.15.0 tables: the two sessions ran on different runtime and OS builds (.NET 10.0.10 →
10.0.11) with a YantraJS bump in between, so no row-for-row delta is claimed here — the comparison
below is directional only. The rank structure is the one 4.15.0 published, with one change of lead
in each table, and they point in opposite directions: array-stress slips out of its rank-1 tie,
leaving V8's compiled lane 1.09× ahead, while interop-collection-traversal puts Jint back into a
rank-1 tie with NiL.JS. Every other row is led by the engine that led it before, and
dromaeo-object-regexp-modern stays Jint's, ~18 ms clear of the nearest V8 lane.

Script ↔ host interop Copy Chapter

Embedding a JavaScript engine is rarely about pure computation — scripts exist to drive the host
application, and in interop-heavy systems the script ↔ host boundary dominates. This is also where
the engines differ structurally: the managed engines dispatch host calls in-process, while every
ClearScript host interaction crosses the managed ↔ native V8 boundary and marshals its arguments
across it.

EngineComparisonInteropBenchmark (run with --allCategories EngineComparisonInterop) drives
four byte-identical scripts against each engine: a host method-call loop, a host property
read/write loop, strings crossing the boundary, and traversal of a host int[]. Details that
keep the comparison fair:

• Host members are lowercase (host.add, host.value, …) because YantraJS camel-cases CLR
  member names while the other engines surface them verbatim — already-lowercase names are the
  fixed point of both conventions, so every engine runs the same source.
• Each script validates its final aggregate and throws on a mismatch, so an engine that silently
  mis-marshals (undefined, NaN) fails loudly instead of posting a fantasy time.
• ClearScript binds the host object with plain AddHostObject (reflection-based, like the
  managed engines); ClearScript_FastProxy uses ClearScript 7.5's FastProxy API — explicit
  member registration with zero-allocation marshaling for fundamental types — its recommended
  path for hot host objects.
• Okojo is absent: 0.1.2-preview.1 provides no public way to enable CLR access.
• As above, Allocated is meaningful for the managed engines but only counts bridge overhead
  for the two ClearScript lanes.

What the numbers show:

• The managed engines win every interop row. Crossing the native boundary costs plain
  ClearScript 8.6×–11.2× against Jint on every row — the mirror image of the pure-compute
  table, and the half of the story that matters most in chatty embedding scenarios.
• FastProxy narrows the gap but does not close it: still 3.4×–7.0× behind Jint, and it
  trades away convenience — every member is hand-registered instead of reflected. Its
  zero-allocation claim is real, though: 13 KB managed allocation on the method-call row where
  reflective ClearScript burns 12,753 KB.
• Jint leads string passing outright, is tied for the lead on collection traversal, and
  allocates the least of the managed engines on all four rows. It is rank 1 on
  interop-string-passing (522.4 µs, ~10% clear of YantraJS) and rank 1 alongside NiL.JS on
  interop-collection-traversal (1,251.0 vs 1,242.7 µs — 0.7% apart, a statistical tie that
  BenchmarkDotNet ranks equal). It is rank 2 on interop-method-calls (NiL.JS ahead, 1,172.2 vs
  1,440.0 µs, Jint +23%) and on interop-property-access (YantraJS ahead, 1,451.9 vs 1,489.8 µs,
  Jint +2.6%). Allocation is Jint's on every row: 3.9×–12.4× less than the row's nearest managed
  competitor. (Three ClearScript_FastProxy rows show smaller KB figures, but those count
  interop-bridge overhead only — V8's working memory is on its native heap.)
• Historical 4.14.0 collection traversal result — last of all engines at 4.13.0 — was transformed at
  15,597 → 1,251 µs (12.5×, −99% allocation) with no script changes: in that release,
  ArrayConversionMode.LiveView was the default and exposed the host array as a live view instead of
  re-copying it on every read, and a per-descriptor value memo
  (#2756) skips re-converting the array on every
  read. NiL.JS took the row back by ~4% in the previous session; here the two are level (0.7%
  apart, both rank 1) while NiL.JS allocates 12× more. The repeated copies in this historical table predate
  the current recent-wrapper cache. Copy is now the default and normally reuses its first snapshot while
  cached; explicitly opt into LiveView to retain shared mutation and avoid the initial O(N) projection.

Engine versions Copy Chapter

• Jint 4.16.0
• NiL.JS 2.6.1722
• Okojo 0.1.2-preview.1
• YantraJS.Core 1.2.422
• Microsoft.ClearScript.V8 7.5.1

Both tables come from one benchmark session on the same machine and .NET runtime (all lanes,
including ClearScript, measured together): 116 benchmarks — 96 script rows (8 lanes × 12 scripts)
and 20 interop rows (5 lanes × 4 scripts) — default job, otherwise idle machine. ClearScript's V8
lanes land within ~3% of the previous (2026-07-28) session on the identical package, so those rows
are broadly comparable across the two — but the ~30% swing those same lanes showed between the
4.14.0 and 2026-07-24 sessions is the standing reminder that the native-JIT rows carry more
session-to-session variance than the managed engines, and that absolute numbers should be compared
within a table rather than across sessions. Two things moved under the whole table between the two
sessions besides Jint itself: YantraJS 1.2.419 → 1.2.422, and the host runtime .NET 10.0.10 →
10.0.11 (SDK 10.0.302 → 10.0.400) on a newer Windows build. Last updated 2026-08-13 (4.16.0
release candidate 7b56c8341).

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.9168/25H2/2025Update/HudsonValley2)
AMD Ryzen 9 5950X 3.40GHz, 1 CPU, 32 logical and 16 physical cores
.NET SDK 10.0.400
  [Host]     : .NET 10.0.11 (10.0.11, 10.0.1126.37416), X64 RyuJIT x86-64-v3
  DefaultJob : .NET 10.0.11 (10.0.11, 10.0.1126.37416), X64 RyuJIT x86-64-v3

Web API rows Copy Chapter

The opt-in WHATWG web APIs under Jint/WebApi/ shipped with a strict no-cost-when-off discipline —
nothing is installed unless Options.WebApi.Features names it, and a default engine is byte-for-byte
the engine it was before they existed. That half was measured. The other half, what the surface costs
a host that does switch it on, had nothing tracking it release to release. These rows are that.

Run the whole category:

dotnet run -c Release --project Jint.Benchmark -- --allCategories WebApi

Unlike the comparison suite, these rows load no files, so it does not matter which directory you run
them from. As everywhere else here, set JINT_BENCH_MODE=gate before quoting any number in a PR.

Check the rows before measuring them Copy Section

dotnet run -c Release --project Jint.Benchmark -- --smoke-webapi

This runs every web-API class's [GlobalSetup] and then each of its rows three times, and reports
pass/fail per class in a few seconds. It measures nothing. Two failures it is there to catch, both of
which otherwise surface half an hour into a benchmark session:

• a row's script throwing — a built-in that moved, or a row asking for the wrong feature flag;
• a row that works once and drifts afterwards. Every deterministic row records what its own first
  run produced and compares every later run against it, because BenchmarkDotNet will happily average
  an operation that is doing more work each time it runs — state accumulating on the row's engine, a
  queue that is never emptied, a buffer that was detached last time and is not now. That check can
  only bite from the second operation onwards, which is why the smoke mode runs each row more than
  once.

Which rows cover which feature Copy Section

The crypto.subtle rows are the operations an embedder runs per request rather than a tour of the
interface — HS256 signing and verification, RS256 and ES256 token validation against fixed imported
keys, and AES-GCM-128 sealing — all over the same 115-byte JWS signing input, so they differ by
algorithm and by nothing else. Each measures one call and its settlement: the script is a single
crypto.subtle call and the row unwraps the promise it returns host-side, which costs no event-loop
turn (the operations are synchronous CPU work and the promise is already fulfilled) but does put the
host-side unwrap ceremony inside the number. Keys are imported in [GlobalSetup], on the row's own
engine, and never in the measured script.

No row covers Console, Base64, Performance, Files, Navigator or Scheduler yet, and
Events is only reached incidentally, through the AbortSignal every Request carries. A PR
touching one of those has nothing here to move, and saying so is the point of this paragraph — the
alternative is a contributor running the category, seeing it flat, and reading that as evidence.

Three properties of these rows are load-bearing and should survive any edit to them:

• One engine per row, warmed with that row's own workload and nothing else — see
  IsolatedScript's doc comment for the measurement defect that rule exists to prevent. It matters
  more here than elsewhere, because these globals are installed lazily and one row's touch is what
  materializes them.
• Each engine carries only its own feature, never WebApiFeatures.Default, so a change to one
  feature cannot move another feature's rows through shared installation cost.
• The timer rows drive a manual TimeProvider. On TimeProvider.System every setTimeout would
  pay a real clock read and a row whose timers fire would be measuring how long the machine took to
  reach a wall-clock instant. Nothing in these rows sleeps, waits or opens a socket — including the
  fetch rows, which build Request/Response/Headers and never call fetch.

The pre-release regression pass Copy Section

Seven rows are the ones to run alongside SunSpider and Dromaeo before a release — one per feature
area, each chosen as the row a regression in its area reaches first:

dotnet run -c Release --project Jint.Benchmark -- --filter "*WebApiUrlBenchmark.ParseAbsolute" "*WebApiUrlBenchmark.SearchParamsMutate" "*WebApiEncodingBenchmark.RoundTripSmall" "*WebApiStructuredCloneBenchmark.CloneNested" "*WebApiFetchObjectModelBenchmark.RequestConstruction" "*WebApiStreamsBenchmark.PumpWithReader" "*WebApiTimerBenchmark.FanOutFiring"

• WebApiUrlBenchmark.ParseAbsolute — the URL parser is the largest hand-written state machine in
  the subtree, and Request construction runs it too.
• WebApiUrlBenchmark.SearchParamsMutate — the other half of Url/: the list, its serializer and
  the URL-object update the setters trigger.
• WebApiEncodingBenchmark.RoundTripSmall — dominated by per-call ceremony (WebIDL argument
  conversion, result-view allocation), which is the cost every one of these APIs shares, so it is the
  row a change to that shared layer moves.
• WebApiStructuredCloneBenchmark.CloneNested — the deepest recursive algorithm in the subtree, over
  a graph carrying a Map, a Set, a Date, a RegExp, a typed array and a cycle.
• WebApiFetchObjectModelBenchmark.RequestConstruction — one row crossing URL parsing, header-init
  conversion, body extraction and AbortSignal creation.
• WebApiStreamsBenchmark.PumpWithReader — promise and job-queue traffic, 256 chunks' worth.
• WebApiTimerBenchmark.FanOutFiring — the event loop's timer promotion, 500 timers per operation.

The last two are worth running for a change to the engine's own event loop as well, not only for
one under Jint/WebApi/: they are the densest promise-and-job workloads in the suite.

No baseline table is published here yet. The first JINT_BENCH_MODE=gate run of a release cycle
establishes one, and a number measured before that has nothing to be compared against.

Overview (`Jint.Browser.Mcp/README.md`) Copy Section

Jint.Browser.Mcp

A Model Context Protocol server over a headless browser, from
Jint and Jint.HtmlParser. An agent
navigates, reads a page as its accessibility tree or as markdown, and clicks, fills and types its way
through it — in one .NET process, with no browser to download and no native binary anywhere.

It renders nothing. Geometry comes from a synthetic flat box model; there are no painted pixels,
screenshots or PDFs. It answers with the page's accessibility tree, prose and text. For an agent that is usually the better
answer anyway, and it costs a fraction of the tokens a picture would.

Using it Copy Chapter

The quickest way is the jint-browser command line, which is this server plus a transport:

dotnet tool install -g Jint.Browser.Tool

Then, in Claude Desktop's claude_desktop_config.json, VS Code's mcp.json, or any client that starts a
server as a child process:

{
  "mcpServers": {
    "jint-browser": {
      "command": "jint-browser",
      "args": ["mcp"]
    }
  }
}

or, in Claude Code:

claude mcp add jint-browser -- jint-browser mcp

stdio is the transport, and the only one. A client starts the program, drives it and ends it, so the
process is the session and its browsing context — its cookies, its storage, its history — is that session's
alone. See Sessions and HTTP below.

In your own server Copy Chapter

// dotnet add package Jint.Browser.Mcp   (net8.0 and later)
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = Host.CreateEmptyApplicationBuilder(null);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .AddJintBrowser(browser =>
    {
        browser.Timeout = TimeSpan.FromSeconds(20);
        browser.UrlFilter = url => url.Host.EndsWith(".example.org", StringComparison.Ordinal);
    });

await builder.Build().RunAsync();

AddJintBrowser registers the browser, the session and every tool and resource below. BrowserAgentOptions
is what a deployment decides: the security posture, the budgets, the ceiling on a snapshot, and the
UrlFilter that pins an agent to one site.

The tools Copy Chapter

Two resources answer about the same session: jint://page/markdown and jint://page/requests.

A ref= is the handle that makes a snapshot actionable. An ax snapshot prints
- button "Save" [ref=42], and click("ref=42") reaches exactly that element — which is what an agent has,
where a CSS selector is something it would have to invent. A reference belongs to the document it was
printed from, so take a fresh snapshot after anything that navigates.

No tool throws through the transport. Each answers its result as JSON, or isError with one sentence
saying what could not be done and what to try instead.

The security posture Copy Chapter

Hardened by default, because a client is by definition pointing this at content nobody vouched for — a
page a model chose, from a search result, from a link in an email. Every page runs Jint's
ForUntrustedContent() profile: no eval, no new Function, no CLR interop, no module loader, and bounded
statements, wall-clock time, allocation, recursion and regular expressions. Loopback, private, link-local and
cloud-metadata addresses are refused.

BrowserAgentOptions.Trusted turns the profile off and BlockPrivateNetwork decides the network rule on its
own, so a deployment pointing an agent at its own staging server says so once, out loud. UrlFilter is the
narrower tool and the one to reach for: it is checked on the first hop and on every redirect.

upload is off until a directory is named, and it is the one tool that can move data outwards. Every
other tool sends a page only what that page already had; an upload sends a file from this machine to a site
the model chose, and a model reading a page is a model that page can try to instruct. So
BrowserAgentOptions.UploadDirectory names the one directory files may be read from — nothing outside it,
and a symbolic link is followed before that is decided — and with no directory named the tool answers an
error rather than a file.

Sessions and HTTP Copy Chapter

A browsing session is state — cookies, storage, history, an open page — and the protocol's 2026-07-28
revision removed the session header from streamable HTTP, so the SDK's HTTP transport is stateless by
default and one server answers every caller. AddJintBrowser therefore registers one browser and one
session for the process, which is exactly right for stdio and wrong for a shared HTTP endpoint.

A host that serves HTTP and needs a session each does it through the SDK's own
HttpServerTransportOptions.ConfigureSessionOptions and RunSessionHandler: build a BrowserAgent per
session there, bind BrowserTools and BrowserResources instances to it, and dispose it in that handler's
finally. That is the SDK's session-ended hook, and it is what AddJintBrowser deliberately does not
assume on your behalf.

What it cannot do Copy Chapter

No screenshots, no PDFs, no layout — so nothing that depends on where a box really is, and no drag and drop.
No iframe scripting, no WebAssembly, no IndexedDB, no media. Images are never fetched; the reference is in
the request log with the reason instead. A hover fires mousemove but not mouseenter, so a menu written
against the latter does not open.

The engine underneath is an interpreter, so a page costs a fraction of Chromium's memory and CPU and some
multiple of its wall-clock time. What the whole stack can and cannot do — and how much of it the
web-platform-tests measure rather than claim — is in
Jint's README.

Licensed under BSD-2-Clause, like the rest of Jint.

HTTP response cache Copy Chapter

The session's HTTP cache is disabled by default. Configure BrowserAgentOptions.HttpCache when embedding,
or pass --http-cache memory, --http-cache-dir --http-cache-partition <visitor-id>, or
--http-cache-temporary to jint-browser mcp. The CLI also exposes finite byte, count and entry-size
budgets. Persistent identities belong to one visitor; temporary storage is deleted on context close.
Closing and reopening the session preserves its configuration. See the
command-line cache options.

Overview (`Jint.Browser.Tool/README.md`) Copy Section

jint-browser

A headless browser on the command line, from Jint and
Jint.HtmlParser. It parses HTML, runs a page's scripts against a real DOM,
follows its network, and answers what the page turned out to be — as markdown, as text, as its accessibility
tree, or over the Chrome DevTools Protocol so that Puppeteer and Playwright can drive it.

It renders nothing. Geometry comes from a synthetic flat box model; there are no painted pixels,
screenshots or PDFs, and there is no browser to download: it runs in one process. What it costs is a
fraction of Chromium's memory and CPU per page; what it costs you back is wall-clock time, because the
JavaScript is interpreted.

dotnet tool install -g Jint.Browser.Tool

Installation and standalone downloads Copy Chapter

Starting with 5.0, installation requires the .NET 10 SDK or later. The SDK selects a self-contained
Native AOT package for the current platform; running it does not require a .NET runtime.

The GitHub Releases page also carries the same executable
as a single-file download, with no SDK or runtime installation required:

Download the file for your OS and architecture and compare its SHA-256 hash with the release's
SHA256SUMS. On Linux/macOS, run chmod +x on the downloaded file, then rename it to jint-browser
and place it on your PATH. On Windows, rename it to jint-browser.exe and place it on your PATH.
No Apple notarization or Windows Authenticode signature is provided.

Linux builds use Ubuntu 22.04 (x64) and Ubuntu 24.04 (arm64), so they require at least those versions'
glibc and the usual .NET native dependencies, including ICU, OpenSSL and zlib. Alpine/musl is not included.
No invariant-globalization mode is used: JavaScript Intl remains available.

Native publishing is scoped to this tool, not a general trimming guarantee for browser library consumers.
To build it from source, use the .NET 10 SDK and the target OS's
Native AOT prerequisites:

dotnet publish Jint.Browser.Tool/Jint.Browser.Tool.csproj -c Release -f net10.0 \
  -r linux-x64 -p:BrowserToolNative=true

Use dotnet pack -p:BrowserToolNative=true on that project without a RID for the NuGet selection manifest,
and once per RID with -r for each implementation package. All seven packages must have the same version;
publish the six implementations before the manifest. The release workflow does this automatically.

Reading a page Copy Chapter

# The page as CommonMark, narrowed to its main content and capped
jint-browser fetch https://example.org/article --main-content --max-length 4000

# The accessibility tree: roles, names and states, one line per node
jint-browser fetch https://example.org/ --dump ax

# The document after its scripts have run
jint-browser fetch https://example.org/ --dump html

# A local file, with its own file: URL as the base
jint-browser fetch ./page.html --dump text

--dump is markdown (the default), text, html or ax. --main-content narrows the answer to the
first <main>, [role=main] or <article> the document has, and --max-length caps it at a word boundary
with a [truncated] marker so a short page and a cut one are told apart; both are refused with --dump html,
because a narrowed or truncated document is not a document. The answer goes to standard output as UTF-8 with
no byte order mark; everything the page's scripts got wrong goes to standard error.

Waiting, headers and cookies Copy Chapter

jint-browser fetch https://example.org/app \
  --wait-until networkidle \
  --timeout 60s \
  --header 'Authorization: Bearer …' \
  --cookie session=abc

--wait-until is commit, domcontentloaded, load (the default) or networkidle — the last being
load plus half a second in which the page made no request, which is what a single-page application needs
before it has anything to read. --header and --cookie may each be given more than once.

Asking a question instead of reading the page Copy Chapter

jint-browser eval https://example.org/ "document.querySelectorAll('article').length"
jint-browser eval https://example.org/ "[...document.links].map(a => a.href)"

The expression is evaluated in the loaded page and its result is serialized by JSON.stringify in the
page, so what comes out is what a script in that document would have got.

Serving the protocol Copy Chapter

jint-browser serve --port 9222

That is a browser on http://127.0.0.1:9222 that Puppeteer, PuppeteerSharp, Playwright, Playwright for .NET,
chrome-remote-interface and the Chrome DevTools front end all connect to over CDP — connect, not launch:

const browser = await puppeteer.connect({ browserURL: 'http://127.0.0.1:9222' });
const page = await browser.newPage();
await page.goto('https://example.org/');
console.log(await page.title());

--port 0 asks the operating system for a port and the banner says which. The endpoint is
unauthenticated, exactly as it is in Chrome: anything that can reach it can run script in this process, so
--host defaults to 127.0.0.1 and should stay there.

--no-images fetches no image at all, which is what a crawler that only reads the DOM wants: each ``
is still listed among the page's requests with the reason it was not fetched, but no socket is opened and
the element fires neither load nor error, so img.complete stays false. fetch and eval take it too.

Serving a browser to an agent Copy Chapter

jint-browser mcp

That is a Model Context Protocol server on standard input and output,
over one browsing session: an agent navigates, reads the page as its accessibility tree or as markdown, and
clicks, fills and types its way through it. In Claude Desktop's claude_desktop_config.json, VS Code's
mcp.json, or any client that starts a server as a child process:

{
  "mcpServers": {
    "jint-browser": {
      "command": "jint-browser",
      "args": ["mcp"]
    }
  }
}

or, in Claude Code:

claude mcp add jint-browser -- jint-browser mcp

mcp hardens the pages by default — the opposite of the other commands, because a client is by
definition pointing this at content nobody vouched for. --trusted turns the profile off and
--allow-private-network lets an agent reach your own machine. The tools, the ref= handles that make a
snapshot actionable, and why stdio is the only transport are in
Jint.Browser.Mcp's README.

Loading content nobody vouches for Copy Chapter

jint-browser fetch https://somewhere-unknown.example/ --untrusted --max-task-duration 2s --memory-limit 256mb

--untrusted hardens every page: no eval, no new Function, no CLR interop, no module loader, and bounds
on statements, wall-clock time, allocation, recursion and regular expressions — plus --block-private-network
on by default, so a page cannot reach localhost, a private address or a cloud metadata endpoint. Pass
--allow-private-network to load a page on your own machine under it anyway.

--max-task-duration and --memory-limit bound one turn of a page — one call the tool makes, one drain
of the event loop, one inline <script> — rather than the run as a whole, which is what a pumped event loop
allows anyone to bound.

HTTP response caching Copy Chapter

Caching is disabled by default. serve, fetch, eval and mcp accept the same cache switches:

jint-browser fetch https://example.com --http-cache memory
jint-browser serve --http-cache-dir ~/.cache/jint --http-cache-partition visitor-42
jint-browser mcp --http-cache-temporary --http-cache-max-bytes 32mb

--http-cache disabled|memory|disk selects storage. --http-cache-dir implies disk mode when no
mode is supplied. Persistent disk storage requires both that directory and an explicit
--http-cache-partition identifying the same visitor across runs. Different visitors must use
separate identities. --http-cache-temporary instead creates a unique disposable directory under the
supplied directory, or the system temporary directory, and removes it on context close. It cannot be
combined with a persistent identity.

The finite limits are --http-cache-max-bytes <size> (64mb), --http-cache-max-entries <n> (1024), and
--http-cache-max-entry-bytes <size> (4mb). Byte units are binary. Invalid combinations and cache limits
supplied with caching disabled are usage errors. An inaccessible cache directory also returns exit code 1.

For serve, the persistent identity belongs to the default browser context. Additional CDP contexts have
independent memory caches or unique temporary disk partitions; they never reuse that persistent visitor's
entries. MCP applies the configuration to its session context, including after close and reopening.
Memory caching lasts for one context; disk persistence can reuse responses across separate tool invocations.

For fetch and eval, --header 'Cache-Control: no-cache' requests validation and no-store bypasses
cache reads and writes. CDP clients can use Network.setCacheDisabled and Network.clearBrowserCache.
See HTTP cache policy and lifecycle for freshness, credentials,
size limits and disk failure behavior. Cache hits still incur consumer body copies.

Exit codes Copy Chapter

A 404 or a 500 is exit code 0: the error page is a document, and it is usually the one a caller
scraping it wants.

What it cannot do Copy Chapter

No rendering, so no screenshots, no PDFs, no canvas and nothing that depends on where a box really is. No
iframe scripting, no WebAssembly, no IndexedDB, no media. Images are never fetched; the reference is
recorded in the request log with the reason instead.

Full documentation of the package under it — what a page can and cannot do, and how much of it the
web-platform-tests measure rather than claim — is in
Jint's README.

Licensed under BSD-2-Clause, like the rest of Jint.

Overview (`Jint.Browser/README.md`) Copy Section

Jint.Browser

A headless browser in one .NET process, from Jint and
Jint.HtmlParser. The native parser supplies the document tree and CSS model; Jint runs
the document's scripts; this package supplies their bindings and the page runtime. It
navigates, runs a page's scripts against a real DOM, follows its network, keeps its cookies and storage, and
answers what the page turned out to be. Its flat box model supplies geometry; it paints no pixels and
produces no screenshots. There is no browser binary to download or launch.

await using var browser = new Browser();
var page = await browser.NewPageAsync();

await page.NavigateAsync("https://example.org/login");
await page.SubmitFormAsync("#login");

var user = await page.EvaluateAsync<string>("document.querySelector('#user').textContent");

A browser can also be published on a Jint.DevTools server
with server.AddBrowser(browser), which makes every page a Chrome DevTools Protocol page target that
Puppeteer, PuppeteerSharp, Playwright and Playwright for .NET drive over connect — in the same process,
with nothing to install. For the command line, see
Jint.Browser.Tool; for an agent,
Jint.Browser.Mcp serves the same page over the Model
Context Protocol.

Requires .NET 8 or later. The Browser library does not currently declare trimming or NativeAOT
compatibility. Native publication of the closed browser tool is a separate consumer contract.

Stylesheet installation loads native @import graphs in source order, resolves nested URLs against
each response's final URL, and bounds cycles without merging sibling sheet identities. CSSOM
insertRule and deleteRule queue import updates after the current script's microtasks; style reads
never fetch. Removed or replaced owners cannot receive stale imported sheets. Import failures are
reported and an initial linked-sheet failure raises the owner's error event before window load.
Encoding currently follows response headers and the inherited encoding; CSS BOM/@charset selection
and response MIME eligibility remain incomplete.

What a page can and cannot do, the per-page budgets, ForUntrustedContent, and how much of it is measured
rather than claimed are in
Jint's README.

Licensed under BSD-2-Clause, like the rest of Jint.

Automatic HTTP caching is opt-in per context; see configuration, HTTP policy and persistence.

Overview (`Jint.DevTools/README.md`) Copy Section

Jint.DevTools

A Chrome DevTools Protocol server for
Jint, so a debugging client can attach to an engine your host is
already running. It speaks CDP over a WebSocket, and a Jint engine appears to a client the way a Node process
does — a target it can list, attach to and evaluate in — with no browser anywhere in the picture. Runtime,
Debugger, Profiler, Console, Log, Target, Browser and Schema answer; everything else is
honestly -32601, which is what a client feature-detects on.

using Jint.DevTools;

var engine = new Engine(options => options.UseDevTools());

await using var server = new DevToolsServer(new DevToolsServerOptions { Port = 9222 });
server.AddTarget(new EngineTarget(engine));
server.Start();

// The host's own loop is what runs the engine AND answers the protocol.
while (running)
{
    engine.Tasks.ProcessTasks();
    engine.Tasks.WaitForScheduledWork(TimeSpan.FromMilliseconds(50));
}

Point Chrome's chrome://inspect at 127.0.0.1:9222, or connect PuppeteerSharp with
new ConnectOptions { BrowserURL = "http://127.0.0.1:9222" }. The endpoint is unauthenticated, exactly as
it is in Chrome: anything that can reach it can evaluate arbitrary script in your process, so Host defaults
to 127.0.0.1 and should stay there.

Requires .NET 8 or later, and is Native AOT compatible — everything the protocol serializes goes through a
source-generated System.Text.Json context, and a published native binary is driven over a real socket in
CI. Jint.Browser adds the page domains (Page, DOM,
Network, Fetch, Input, Emulation, Storage, Accessibility) on the same session core.

Which thread answers a command, what each domain answers, and how to try it from the REPL are in
Jint's README.

Licensed under BSD-2-Clause, like the rest of Jint.

Overview (`Jint.HtmlParser/README.md`) Copy Section

Jint.HtmlParser

Jint.HtmlParser is an experimental native markup package for .NET 8 and .NET 10. Its public API is provisional until ACC-06 (external package and API acceptance) in the
acceptance tracker
is explicitly closed. Internal Browser use and API snapshots do not close that gate. Public signatures,
behavior and value-type layouts may change between prereleases, including positional record structs such
as ShadowRootInit and BoundaryPoint; pin a tested package version when integrating.

The package remains prerelease even when Jint releases GA. Existing prerelease inputs are preserved
(for example 5.0.0-preview-123); stable version inputs become 5.0.0-experimental-0 by default,
or 5.0.0-experimental- when a build number is supplied. This applies to explicit
Version and PackageVersion overrides as well as the normal prefix/suffix calculation. The numeric
base follows the repository release; it is not a promise that this package's API has frozen.
Promotion to a stable parser package requires a separate reviewed change removing the build policy
and recording the external acceptance evidence. Jint.Browser can retain its repository release version
while declaring the calculated prerelease parser dependency.

The API usage guide covers installation,
parsing, tree manipulation, CSS syntax, XPath, serialization, limits and threading.

Its implemented public surface includes:

• A mutable document tree with elements, attributes, text, comments, CDATA and processing instructions.
• Inert HTML document and contextual fragment parsing through MarkupParser.ParseHtml and ParseHtmlFragment, with lexical limits and bounded diagnostics.
• XML document and fragment parsing through MarkupParser.ParseXml and ParseXmlFragment, and strict SVG-root parsing through ParseSvg.
• CSS Syntax parsing of whole stylesheets, rules, declarations and component values. These methods return syntax, without CSS property validation or computed styles.
• Native mutation subscriptions with explicit record draining through Document.ObserveMutations.
• Explicit HTML/XML serialization through MarkupSerializer, with output limits, cancellation and selected native shadow roots.
• XPath 1.0 compilation, evaluation and selection through NativeXPath, preserving namespaces and native result identities.

using Jint.HtmlParser;

var document = MarkupParser.ParseXml("<root><item/></root>");
var root = document.DocumentElement!;
var fragment = MarkupParser.ParseXmlFragment("<next/>", root);
root.AppendChild(fragment);

XML parsing defaults to a ceiling of 10,000,000 UTF-16 entity replacement units, including when
other limits are supplied through new ParseLimits(). Select ParseLimits.Unbounded or explicitly
set MaxEntityExpansionCharacters = 0 only for trusted inputs. Exceeding a limit raises
ParseLimitException, separately from XML syntax errors.

XML results expose immutable SkippedXmlEntities, XmlNotations and
XmlDtdProcessingInstructions inventories. DTD instructions retain target, data and original UTF-16
offsets in encounter order (including repeated parameter-entity invocations). They are parse metadata,
not DOM children: DOM serialization and XPath do not relocate them into the document. Document
clones preserve these inventories; importing/adopting nodes or parsing a fragment does not transfer
or overwrite them. No external resolver is exposed.

HTML parsing recovers malformed markup and creates implied document structure. Fragment results belong to the context owner document and leave existing children untouched. HtmlParseOptions.ScriptingEnabled changes grammar without executing scripts. Native HTML parsing performs no network requests.

Input length and token limits default to zero (disabled); CSS nesting also defaults to zero.
The finite XML entity ceiling is not an overall memory or time budget. Supply bounds suited to your input
and a cancellation token for cooperative cancellation. For example:

var bounded = MarkupParser.ParseHtml("<p>Hello</p>", new HtmlParseOptions
{
    Limits = new ParseLimits { MaxInputCharacters = 100_000, MaxTokenCharacters = 20_000 }
});

Whole-sheet CSS parsing returns immutable syntax and the exact original source:

using Jint.HtmlParser;
using Jint.HtmlParser.Css;

CssStyleSheetSyntax sheet = MarkupParser.ParseCss("@future x; p { color: var(--theme); }");
foreach (CssRuleSyntax rule in sheet.Rules)
{
    string originalRule = sheet.Source.Substring(rule.Span.Start, rule.Span.Length);
    Console.WriteLine(originalRule);
}

ParseCss consumes the whole input with standard CSS Syntax recovery; empty input succeeds.
Rules expose immutable preludes and nested token, function and block components with original UTF-16 spans.
Unknown at-rules, unsupported properties, invalid property values and pending substitutions remain syntax.
Parsing does not validate selectors or properties, resolve URLs, load imports, attach styles, or compute a cascade or geometry.
CssParseOptions supplies the existing limits and optional diagnostic collector; cancellation is supported.
The result retains no parser, options or collector. Public mutable CSSOM promotion and equivalent CSSOM benchmarks are separate work.

Serialization selects its format explicitly, without moving nodes or fetching resources:

string html = MarkupSerializer.ToHtml(document);
string xml = MarkupSerializer.ToXml(document, requireWellFormed: true,
    limits: new SerializationLimits { MaxOutputCharacters = 100_000 });

ToHtmlChildren and ToXmlChildren omit the container's tags and use template contents where appropriate.
requireWellFormed enables the DOM Parsing algorithm's checks; it is not general XML/DTD validation.
Output-limit failures throw SerializationLimitException without returning partial output.
Normal HTML output omits attached shadow roots. Element.AttachShadow returns the real native
ShadowRoot (even for closed mode); OpenShadowRoot exposes only open roots. Pass roots explicitly
in HtmlSerializationOptions, or pass serializableShadowRoots: true to include reachable roots marked
serializable. Attachment does not execute Browser custom-element reactions or resolve its definitions.

XPath expressions can be reused across documents:

NativeXPathExpression expression = NativeXPath.Compile("//item");
IReadOnlyList<object> nodes = NativeXPath.Select(document, expression);
double count = NativeXPath.Evaluate(document, "count(//item)").NumberValue;

Unprefixed XPath element tests match no namespace; use a namespace resolver for HTML/XML namespaces.
Contexts can be a Node, an attached/detached non-XMLNS Attr, or a captured XPathNamespaceBinding.
Results contain only native nodes, attributes and namespace bindings. Membership and captured scalar
values remain stable after mutation; the selected native objects themselves are not frozen.
Reusing a namespace context rejects a binding whose URI is no longer in scope. No BCL cursor or
mutable expression escapes. Cancellation brackets BCL work but is not a hard timeout during its
non-preemptible compilation/evaluation intervals.

Jint.Browser now uses this native tree, parser and CSS model. Neither production packages nor tests
depend on AngleSharp. AngleSharp, AngleSharp.Css and AngleSharp.Xml remain only in Jint.Benchmark
as comparison controls; dependency removal is not a claim of complete behavioral parity.

Threading Copy Chapter

After parsing finishes and the tree is safely published to other threads,
concurrent immutable inspection of tree links, node names, character data and
attribute values is supported, including cold Text.Data/Attr.Value getters,
text-content reads and serialization with separate per-call state. Keep the tree
unchanged for the entire read operation. Parsing sessions, mutation, adoption,
live ranges/iterators and mutation subscriptions require one writer and external
synchronization with all readers; one writer alone does not make overlapping
reads safe. Operations that initialize mutable DOM state or indexes (including
selector/id queries, form-control state and processing-instruction attribute
views) also require external synchronization. This is not a blanket thread-safety
promise for every method that looks like a read.

Jint.Browser page trees retain their page-loop affinity: access them through the
page's scheduled operations. The standalone parser's immutable-read support does
not permit reading a live Browser DOM from another thread while its page can run
script, parse or mutate it.

Contributor documentation Copy Chapter

Implementation contracts, regeneration, corpus maintenance and package verification belong in the
contributor guide.
The acceptance tracker
records remaining work; dependency removal does not establish complete behavioral parity.

Renderless CSS boundary Copy Chapter

The renderless CSS contract
defines Browser's text-value scope and the deliberately limited declaration grammar.

Browser integration contract Copy Chapter

The Browser integration contract
defines reviewed internal hooks, snapshots and parser/Browser ownership.

Overview (`Jint.Tests.Test262/README.md`) Copy Section

To generate test suite, run:

dotnet tool restore
dotnet test262 generate

A build does this for you whenever Test262Harness.settings.json or .config/dotnet-tools.json
changes. The generator pinned in .config/dotnet-tools.json and the Test262Harness library pinned
in Directory.Packages.props come from one release and carry the same version; the build fails while
they differ.

The test run downloads the archive for the generated suite's exact SuiteGitSha into a unique
staging directory, verifies the pinned corpus content digest, and atomically publishes it to the
cache. Transient acquisition failures are retried up to three times. Set JINT_TEST262_CACHE to
choose the directory that holds test262-<sha>.zip. Set JINT_TEST262_OFFLINE=1 to require that
exact cached archive and disable network acquisition; a missing, partial, corrupt, or mismatched
archive fails the run rather than falling back to another corpus.

Reusable provider examples Copy Chapter

NodaTimeZoneProvider.cs and IcuCldrProvider.cs in this directory are not just test
fixtures — they are working examples of the provider extension points described in the
internationalization guide. The test
suite reaches its current test262 conformance numbers by registering them on the
Engine.Options.Temporal.TimeZoneProvider and Engine.Options.Intl.CldrProvider
properties; end users can copy these files into their own projects (with the matching
NodaTime / ICU4N NuGet packages) to get the same behaviour.

Overview (`docs/README.md`) Copy Section

Jint documentation

The documentation site is built with VitePress.

Run locally Copy Chapter

From the repository root:

cd docs
npm ci
npm run dev

VitePress prints the local URL, normally http://localhost:5173/.

Build the production site Copy Chapter

cd docs
npm ci
npm run build
npm run check-links
npm run preview

GitHub Actions runs the same production build for pull requests. A push to
main that changes the site or its workflow publishes the result to GitHub
Pages.

The link checker reads the generated site under its configured base path. It
validates internal pages, assets, and heading anchors without requesting
external URLs, so links to packages or services that are not published yet do
not block the build.

Validate documentation changes Copy Chapter

From docs/:

npm run test:tools
npm run samples:check
dotnet build snippets/Jint.Documentation.Samples/Jint.Documentation.Samples.csproj -c Release
DOCS_BASE=/jint/ npm run build
DOCS_BASE=/jint/ npm run check-links
npm run lint

Compiled C# samples Copy Chapter

High-traffic examples are maintained as #region docs:name blocks in
snippets/Jint.Documentation.Samples. The sample project compiles in Release,
and the Markdown references each region with stable markers:

Run npm run samples:sync after changing a sample. Commit the resulting
Markdown so GitHub, NuGet.org, and the documentation site all show the reviewed
code. CI runs npm run samples:check and fails if a block is stale or missing.

Native parser documentation Copy Chapter

The docs-site API guide covers standalone API usage with compiled
examples. The package README
covers standalone embedding. The contributor guide
covers parser contracts, regeneration, corpora and package verification, and the
acceptance tracker records open gates. Markdown lint covers both
package and contributor documents; the instruction guardian tests check parser routing and local anchors.

Overview (`Jint.Benchmark/ParserCorpus/README.md`) Copy Section

Parser comparison corpus

These twelve UTF-8 inputs were written for this repository and are distributed under its
BSD 2-Clause license. They use fixed counts and names; none downloads content,
samples a live site or depends on a random seed. The files are copied to the benchmark output directory.

HtmlParserCorpusBenchmark parses each source into a complete AngleSharp document, stylesheet or
declaration block. HTML and the two error-recovery cases use the HTML parser. Standalone SVG and XML
use the XML parser; inline SVG in html-small.html exercises the HTML foreign-content rules. The
source string and parser instance are prepared in GlobalSetup; each measured operation creates a
fresh result. The case label includes UTF-8 input bytes, and [MemoryDiagnoser] tracks managed
allocation per operation.

Run dotnet run -c Release --project Jint.Benchmark/Jint.Benchmark.csproj -- --validate-html-parser-corpus from the repository root to parse all inputs without timing them.
It compares the resulting tree/rule counts with pinned AngleSharp shapes and checks HTML entities,
rawtext, template content, namespaces, table repair, XML CDATA and values, and CSS property values
inside conditional rules and keyframes. The shape includes a template's content fragment and XML
CDATA text. Count-preserving value mutations in HTML, XML and CSS must fail validation. These
pinned counts detect accidental fixture or baseline changes; they are an
AngleSharp reference, not a standards oracle.

XmlSvgParserComparisonBenchmark pairs the four standalone XML/SVG inputs with the public
MarkupParser.ParseXml and ParseSvg APIs. Its AngleSharp row is the control. Both rows receive
the same loaded string, keep parser configuration outside the timed method, and return a fresh,
complete document. dotnet run -c Release --project Jint.Benchmark/Jint.Benchmark.csproj -- --validate-xml-svg-parser-comparison compares the trees without timing. The comparer checks node
kinds, element and attribute names, prefixes, namespaces, values and order, text/CDATA, comments,
processing instructions, doctypes, parent links and owner documents. It also rejects deliberate
count-preserving changes to content, node kind, attribute order, regular attribute namespace and
SVG XLink value. A separate untimed XML input exercises an internal entity, PI and doctype because
the four throughput fixtures do not all carry those constructs.

The XML comparison uses default, unbounded parsing with no external entities in the inputs.
This is an equal parse workload with a documented default-xmlns representation difference,
not a claim of identical DOMs. Pinned AngleSharp.Xml 1.2.0 reports the unprefixed xmlns
declaration with a null/empty namespace; the native DOM reports the XMLNS namespace. Outside
timing, the comparer requires precisely those two tuples, including the same name, value, position
and owner. A prefixed xmlns:m or xmlns:xlink declaration must use XMLNS on both sides; ordinary
attributes and elements require exact namespace equality. Deliberately wrong declaration tuples,
missing or reordered declarations, and corrupt descendant bindings are rejected. The rows compare
parsed trees; SVG document MIME branding differs between the generic AngleSharp XML entry and
native ParseSvg.

HtmlParserComparisonBenchmark pairs the four HTML inputs with public MarkupParser.ParseHtml.
Both rows receive identical cached strings, reuse scripting-disabled configuration, retain no
source references or diagnostics, and produce fresh complete documents. Setup checks all node
kinds, values, attribute order/namespaces, child order, template subtrees and owner/parent links.
Untimed corruption probes exercise content, attributes, comments, namespaces and ownership.
Run --validate-html-parser-comparison for these checks without starting a timing run.

HtmlControlsParserComparisonBenchmark adds three separate pairs over 256 text/url/email/password
inputs: parsing alone, parsing plus first value access, and warm value access. First access includes
a fresh parse and control-array construction on both sides; warm access has row-owned parsed
documents and control arrays outside measurement. Setup verifies identical values and that native
parsing leaves input value sidecars absent. These rows deliberately expose deferred sanitizer cost.
URL and email values are already canonical: the pinned AngleSharp getter preserves surrounding URL
spaces while native HTML normalization removes them, so such inputs cannot establish equal observable
value workloads. Setup compares each control value, not only a checksum.
The native semantic row invokes the production native input-state accessor through benchmark
internal access; it does not claim a public parser-package semantic API.

CSS remains AngleSharp-only: native public CSS Syntax results are not comparable to AngleSharp
CSSOM output. A future candidate must return a fully materialized result of the same kind and validate it during
setup. A tokenizer-only row would not be comparable to document-producing rows. Use the
repository's paired benchmark procedure for reported timing numbers; no timing results are
recorded with this corpus.

Overview (`Jint.Benchmark/ParserPrimitives/README.md`) Copy Section

Markup parser primitive comparisons

Dedicated decision benchmarks for the native HTML/XML parser work. These compare equivalent small
operations, not Markdown against HTML or a scanner against a complete parser. They change no runtime
parser behavior. The newest supported benchmark TFM is net10.0, selected by the existing project;
do not add older runtime jobs or an installed preview runtime to these comparisons.

What Markdig actually does Copy Chapter

Source inspected at commit 56e9c238584a44a169f174c881855c049768634c, dated 2026-09-20:

The tree supports prefix operations, but this Markdig HTML call uses exact matching. Its case folding,
CommonMark tag grammar and whitespace semantics must not be imported into HTML/XML rules. The bit-mask
candidate here tests the same technique with HTML's five ASCII whitespace characters; it is not a copy
of Markdig's full Unicode whitespace helper. The bool array similarly specializes the ASCII indexing
idea; these rows do not claim to measure the generic CharacterMap itself. No Markdig source or runtime
dependency is vendored by this benchmark.

The current Jint comparison targets were inspected in integration commit 37c8a6712:
Html/HtmlTokenizer*.cs character classification, Html/HtmlInput.cs input boundaries, and
Html/TreeConstruction/HtmlTreeBuilder.Body.cs::IsBlockStart. XML's whitespace excludes form feed, and
XML scalar/name validation has separate rules. These HTML kernels are not replacements for those checks.

Equal work and units Copy Chapter

All hot tables/configuration and input strings are created outside timing. Each method consumes the
same input and returns a count/checksum used by BenchmarkDotNet. No engine or mutable shared parse state
exists. Lookup input strings are freshly materialized rather than interned literal hits.

Every class reports Op/s and Allocated B/op through BenchmarkDotNet. Construction rows separately
expose the cost hidden by hot static reuse; their allocation totals are not retained-heap measurements.
No-table patterns have no lookup construction to measure. Do not compare character Op/s to buffer Op/s,
or claim a parser throughput increase from these kernels alone. The delimiter set is exactly <, &,
CR and NUL; ordinary LF and Unicode are deliberately not equivalent delimiter substitutions.

The full suite currently has 33 parameterized rows. Small fixed sets can already be compiled efficiently
from or; the collection candidates are hypotheses, not a presumption that a lookup is faster. A frozen
set benefits from static lifetime and can lose for short names or miss distributions. Table initialization
must be included in a later end-to-end experiment if the proposed lifetime is per parse.

Validation and measurement Copy Chapter

Correctness-only, with a fresh Release build:

dotnet run -c Release -f net10.0 --project Jint.Benchmark/Jint.Benchmark.csproj -- --validate-markup-primitives

This checks every UTF-16 value for whitespace equivalence; sliced/randomized delimiter buffers,
including exact first-match offsets at every suffix, NUL, CR, surrogate code units and SIMD-sized
boundaries; exact tag cases; and each configured benchmark's result. A failure aborts independently
of timing. Each GlobalSetup also verifies its own input. These checks exercise search semantics,
not XML well-formedness or full HTML parser conformance.

Run on an otherwise idle machine, using the repository's benchmark environment instructions:

JINT_BENCH_MODE=gate dotnet run -c Release -f net10.0 --project Jint.Benchmark/Jint.Benchmark.csproj -- \
  --filter '*MarkupCharacterMembershipBenchmark*' '*MarkupDelimiterScanBenchmark*' \
           '*MarkupTagMembershipBenchmark*' '*MarkupLookupConstructionBenchmark*' \
  --exporters json csv

The local class config adds only Op/s; it does not replace the repository job, select another runtime,
disable tiering/PGO or bypass the busy-machine check. Do not use --job short results, --no-build,
concurrent builds/tests, or machine-idle overrides to decide a winner. Keep runtime/architecture, commit,
raw reports and environment metadata with results. Latest TFM alone does not establish portability
between x64 and Arm64. Treat small differences as inconclusive until the repository's repeat/paired
measurement requirements are met.

No timing results have been recorded yet. A coordinated idle measurement window is required while the
parser implementation work runs in other worktrees.

Adoption gate Copy Chapter

Keep a candidate only when it wins the relevant distributions without harmful allocation or startup
tradeoffs. Before changing a parser, prove the exact grammar/state set and retained character/offset
semantics. A vectorized scan must stop at the proper chunk boundary, charge all skipped work, poll
cancellation at the established cadence, respect quotas and preserve CRLF/NUL/Unicode handling.
Cached sets belong to immutable grammar data, not engine/document/host state.

Runtime feature owners make any resulting optimization as a separate reviewed change. Run the full
affected conformance tests and a paired equal-work whole-parser benchmark afterward. These primitive
rows inform that work; they do not replace the standalone API, Browser parity or production dependency
removal gates.

Overview (`Jint.Browser/Styling/README.md`) Copy Section

Native styling boundary

Browser follows the renderless CSS boundary.
NativeCssStyleSheets.Install stores owner identity, source/base URLs, source text and resource
revision. It does not parse inline attributes, run the cascade or perform layout. NativeCssParsing
owns demand-driven rule/media caches; inactive bodies stay raw until CSSOM inspection or matching
requires them. Imports load without parsing unrelated rule bodies.

NativeCssQuery memoizes matching sources and requested text values for one synchronous query.
It checks document, resource, imported-sheet graph, inline-block and Browser read witnesses.
Matching occurs once per element/query, including native shadow scope and slot/host inheritance.
No state is attached to native nodes. Origin, importance, encapsulation, inline style, layer rank,
specificity and source order select declarations; inherited properties and catalog defaults fill gaps.
Explicit revert/revert-rule/revert-layer values retain cascade rollback.

Values are text, not typed grammars. Custom properties inherit declared text. Ordinary values may
use bounded textual var() substitution with fallbacks (depth 32; expansion limit 1,000,000 characters).
It is not token substitution: no declaration-scope resolution, deferred shorthand evaluation, typed
functions, URL resolution or unit computation. Colors stay declared text in the cascade; ResolvedStyle
serializes color longhands as rgb()/rgba() only at the CSSOM and DevTools read boundary. A missing/cyclic expansion defaults
the property rather than selecting an earlier declaration. Substitution-produced rollback keywords
remain text. Simple display blockification stays; overflow axes no longer compute together.

The data catalog supplies a small initial-value table and inherited flags; other known names have
empty initial text. Only layout-used shorthands expand by whitespace splitting. ResolvedStyle
returns synthetic box width/height where available and text otherwise. Text extraction interprets
white-space keywords locally. DevTools and CSSOM consume the same values and native rule identities.

Style, media, supports, layer, import and font-face rules retain real models and mutation identities.
Other at-rules are plain CSSRule objects preserving cssText and never entering the cascade.
Font-face descriptors remain passive text. CSS.supports tests known/custom names and nonempty values,
with the existing condition/selector parser, not property grammars.

Keep CssValueWork and selector work checks in surviving loops. Cancellation and reentrant edits
must not publish obsolete state. Computed declarations stay read-only and live across later reads;
borrowed cross-realm mutator exception branding remains separate binding work.

Overview (`Jint.Tests.Browser/Wpt/README.md`) Copy Section

The web-platform-tests browser lane

The .any.js lane hands a file to an engine. This one loads a document: a vendored .html is served by
WptServer at a real URL, a Browser navigates a fresh Page to it, and the document pulls in upstream's own
resources/testharness.js through a <script src> exactly as a browser does. The realm is a real Window
with a document, a `` and a load event, so the harness deciding what passed is upstream's and
there is nothing of Jint's between the corpus and the verdict. A document that drives input reaches
test_driver, and that goes through the same InputDispatcher the Input domain does — the
testdriver-vendor.js slot upstream ships empty is where the two meet.

The corpus is vendored once. Everything here runs out of Jint.Tests/Wpt/Vendor/, at the commit
Vendor/README.md names, byte-verified the way that file describes;
this project holds no copy of a vendored file. How the lane works — the results overlay, the synthesized
wrappers, the environment a document runs in, where a divergence goes — is
AGENTS.md beside this file. What follows is what the lane found.

This is not the only web-platform-tests number, and the other one is not a rival. The census below is
ours — our driver, a vendored subset, an exclusion row per failure — and it is a gate. The
scoreboard is
upstream's: a nightly wpt run over wptserve, across ten whole suites, and it gates nothing. It runs
the same corpus at the same pin, so a suite it reports that this table does not have is a suite nobody has
vendored here yet. Its plugin is tools/wpt-scoreboard/.

The lane, suite by suite Copy Chapter

Measured on Windows. Documents are .html files in this repository; Synthesized are the
<name>.any.html wrappers WptServerWrappers manufactures for a suite's .any.js files, which are bytes
nowhere. Not passing is a ceiling: a rise fails as a regression naming the suite and the size of it, a
fall fails as staleness, and the rewrite refuses to write a larger figure. Take the census with

# check the table (about ten seconds; it runs every document)
JINT_WPT_BROWSER_CENSUS=1 dotnet test --project Jint.Tests.Browser -c Release

# rewrite it from what the lane measures, then commit the diff
JINT_WPT_BROWSER_CENSUS=update dotnet test --project Jint.Tests.Browser -c Release

JINT_WPT_BROWSER_CENSUS=update-raising-the-ceiling is the one spelling that may write a larger
not-passing figure, for a corpus bump that genuinely arrives with new failures.

A case is a document at one variant, and that is why Tests can move without Documents moving.
A document may carry <meta name="variant" content="?query">
elements; upstream's manifest then makes one test per declaration, at the document's path with that
string appended, and the document reads which one it is out of location.search. This lane enumerates
them the same way and names a case exactly as the manifest names it —
dom/ranges/Range-in-shadow-after-the-shadow-removed.html?mode=open — so an exclusion, a minimum-test
entry and a cause all key on the case, and there is deliberately no spelling that means every variant:
two variants are two runs, and a divergence measured in one is not evidence about the other. Two vendored
documents declare any, and both pass at every one of their five variants between them:
dom/events/handler-count.html (?document, ?window, ?element) and
dom/ranges/Range-in-shadow-after-the-shadow-removed.html (?mode=closed, ?mode=open). The engine
lane's answer is the opposite one and is not a contradiction: // META: variant= sharding is ignored
there because one unsharded run of a .any.js file is the union of its ?1-1000 shards, while a query a
document branches on selects different tests that no single run is the union of.

What this corpus says about this browser Copy Chapter

The eleven defects this lane first recorded are fixed. They were filed as
#3686 to
#3695 — document.createEvent and the document
constructors, window.event, the report of a script's exception, the compiled handler's shape and scope, the
body's window-forwarded handlers and HTMLFrameSetElement, the legacy UI-event initializers, the default
passive value, one activation behaviour per click, the detached control's silent toggle, and named access on
the window — and the three seams two of them needed in the engine are
#3696.

Two more left NeedsTriage with the script-loading path, and both were about a URL. A data: URL is a
subresource now: ParserDriver answers the data arm of
scheme fetch out of
Fetch §5.2's processor rather than over a socket, so
<script src="data:text/javascript,…"> runs and the three processing-model-2/ documents about it pass.
And a subresource's response URL carries its fragment, which is what
Fetch says a response URL is — the fragment is left
out of the request-target and of nothing else — so <script src="support/syntax-error.js#"> reports the #
that the same element's src already reflected, instead of losing it to a re-serialization. Five rows and
two; the same processor also replaced the page's second, open-coded data: decoder, so a navigation to
one now reads its charset and takes a payload Convert.FromBase64String refuses.

What NeedsTriage holds now is one thing, and the exclusion table names it: a form-associated custom
element has no form owner. window.customElements exists now, and the one row of
compile-event-handler-lexical-scopes-form-owner.html that is left asserts that a compiled handler on an
<x-foo static formAssociated> sees the form's lexical scope — which needs the element to be a
form-associated element and take part in form.elements. This package records the flag and nothing
consults it: there is no ElementInternals. The file's other three rows pass.

@@unscopables was another of them, and it is gone. WebIDL puts one on the interface prototype object of
every interface with an [Unscopable] member, the former DOM integration's metadata cannot say which members those are, and
the answer is an unscopables list in overrides.json — the standard's half of the table, the way
reflected is — rather than a hand-edited .g.cs. DOM §4.2.8 and §4.2.9 mark every member of ChildNode and
ParentNode, which is seven names on Element and three or four on each of the other four interfaces that
include one; compile-event-handler-symbol-unscopables.html and dom/nodes/remove-unscopable.html pass
whole, nine rows between them. It matters outside a conformance suite for one reason: HTML compiles an inline
event handler with the element, its form owner and the document on the scope chain, so without it
`` calls the element's remove() instead of the page's own global.

The twenty-two <a>/<area> shapes of Event-dispatch-single-activation-behavior.html were the last of
them, and they pass now. What kept them red was not the page loop's scheduling but the fragment arm being
gated on the page's own load having returned and on the navigation gate being free: this file's tests run
during the parse, where neither is true, so every one of their fragment moves was queued as a whole
navigation behind the gate and landed after the two turns the file allows. The move is a same-document one
exactly when the request came from the document the page is showing, which is the question
Jint.Browser/Runtime/AGENTS.md
now says it asks.

The five interfaces document.createEvent's alias table named that this package did not build — DragEvent,
StorageEvent, TouchEvent and the two device events — are built now, and the category they had
(NeedsMoreEventInterfaces) is empty. What unlocked them was separating two questions the old reason ran
together: whether the runtime ever fires such an event, and whether a page can construct and dispatch one.
Only the second is what the corpus tests and what the alias table needs, so each interface is built from its
own dictionary in full — DragEvent over the DataTransfer this package already has for file inputs,
StorageEvent with the initStorageEvent Web Storage still carries, TouchEvent with Touch and
TouchList, and the two device events with the two readings a motion event carries — while nothing fires any
of them and each class says so. EventTarget-dispatchEvent.html passes whole, and the six rows of
Document-createEvent.https.html the file itself guards with assert_implements_optional('ontouchstart' in document) pass too: touch detection belongs to a client here (Runtime/TouchEmulation), so the lane opens
that one document as a touch device (WptBrowserExclusions.TouchDocuments, an environment rather than an
exclusion) and the row left in the file is its TextEvent one. And eight rows of
Event-dispatch-single-activation-behavior.html moved to AssertsWhatNothingRequires: the file's
instrumentation is a <form onsubmit> handler and cannot tell an activation behaviour from an ordinary
bubble, and submit and reset both bubble.

What the custom element corpus says Copy Chapter

custom-elements/ and its parser/, reactions/ and upgrading/ sub-directories arrived with the
implementation of HTML §4.13, and the shape of what is missing from that corpus is one sentence: most of
it is written against a second global. resources/custom-elements-helpers.js gives it
create_window_in_test, which loads an iframe and resolves with its window, and document_types(), which
makes every assertion in five documents — this one, a new Document(), a createHTMLDocument(), an
iframe's and an XHR-fetched one. Same-origin, unsandboxed sourced frames now have independent realms and
run classic scripts on the page's loop. Their DOM constructors and node creation brands are distinct, and
their window listeners, timers and microtasks run against the child global. Empty iframes and child-specific
custom-element registries and reaction delivery remain #3771.
Thirty-seven documents stay in the not-vendored table pending those capabilities and re-examination.
Re-vendoring moves the census's Documents and Tests columns and requires measuring each document.

The native acceptance run leaves these distinct causes:

1. The parser upgrades a custom element where HTML constructs one. The native session hands
   script execution to Browser, but still lacks the element-construction handoff. Attributes already exist
   when an upgrade runs. Native insertion now yields before children so Browser drains attribute and
   connection reactions at the semantic boundary, independently of tokenizer quotas. The document.write
   connection-timing case and the two corresponding ordinary-parser reaction checks pass without
   exclusions. Synchronous construction and constructor-failure semantics remain debt.
2. Cross-document and namespace-sensitive reactions remain incomplete. Retained exclusions name
   the exact adoption, registry and attribute callback assertions. They are not blanket exclusions for
   native attribute storage, cloning or ordinary mutation delivery.
3. Some CSS computation and grammars are still missing. Web Animations now passes the unobserved-style
   reaction case. Its two observed-style cases require interpolation from a synthetic underlying-style
   keyframe: discrete commitStyles() has no value to write before the single supplied keyframe at offset 1.
   Those two assertions are NeedsLayout, not missing animation APIs or a broken reaction bridge.
   CSSStyleDeclaration exclusions now cover only the failing float, border-width and prefixed-filter
   assertions, not the whole document.

ARIA reflection, dataset writes and Selection deletion now share native mutation preparation/completion.
Their four reaction documents pass without exclusions. Historical nullable-namespace and CSS serialization
failures are no longer reasons to exclude passing native assertions.

builtin-coverage.html is green now, all four hundred and forty-four rows of it. Its 'new' and
createElement halves were two hundred and twenty-two rows of one defect, and the defect was not the
customized-built-in path at all — its innerHTML and parser halves always passed. Every one of those rows
failed on customized.cloneNode().constructor: DOM creates a clone with the element's is value, which is
a slot that createElement(tag, { is }) and new XY() set without adding an attribute, and the former DOM integration's
clone copies attributes and nothing else. So the two halves that set the slot cloned into a plain built-in
and the two that write the is attribute in markup did not. custom-elements/upgrading/'s own row was the
same rule read from the other side — a clone must follow the slot even when the is attribute says
something else — and it went with it.

Two more things the corpus found are not defects and are recorded where they belong instead.
Element.insertAdjacentText is missing, which upstream's own result renderer calls — the overlay turns the
renderer off for its own reasons and AGENTS.md says so rather than letting that line hide it. And
Event.timeStamp is not coarsened, which PerformancePrototype records as a deliberate divergence; the one
document whose subject is that resolution is in the not-vendored table for the reason
performance-timeline/webtiming-resolution.any.js is out of the engine lane.

The image element, and the four documents that fit here today Copy Chapter

html/semantics/embedded-content/the-img-element/ arrived with HTML §4.8.4.3's image request, and all four
of its documents pass with no exclusions. Image-constructor.html's five tests are the
[LegacyFactoryFunction]'s shape — the name, the prototype it shares with HTMLImageElement, the descriptor
of Image.prototype. nonexistent-image.html could not have passed before the model existed, because it
waits for an error event this browser had no image request to fire. And the two the source set added are
the ones that made it worth writing: update-the-source-set.html is 89 tests over §4.8.4.3.6 itself —
every descriptor form, the sizes lengths, a 's `media` and `type`, and the tokenizer's own corner cases — and `img-picture-ancestor.html` is the four about which an `` belongs to. Both are
written entirely in data: URLs, which is why they can run in a corpus that vendors no image.

update-the-source-set.html is also the one that found two defects nothing else had asked about. A media
query that does not match the grammar is not all, so not all and ! is false — MediaQuery answered
true, and matchMedia said so too. And a srcset candidate's URL is delimited by white space rather than
by a comma: srcset="data:,b" is one candidate whose URL contains a comma, and a Split(',') turned it
into data: — which is a URL, so nothing downstream could have noticed.

Four documents out of a hundred and sixty is deliberate, and the reason is what the directory is made of.
Most of the suite is a rendering test: image-loading-lazy-* alone is thirty-odd documents about whether an
image is inside a scrolling area, available-images.html and its siblings are reference tests compared
pixel-by-pixel, and a dozen more draw the loaded image into a <canvas> and read the bytes back. Of what is
left, img.complete.html and naturalWidth-naturalHeight-width-height.html are the two whose subject is
exactly this model — and each needs upstream's photographs, a 91 kB and a 380 kB JPEG, plus
?pipe=trickle(d1) server-side throttling for the assertion that complete cannot change inside a task.
This corpus vendors no binary at all today, and adding half a megabyte of them is a change of its own rather
than a passenger on the one that made the model exist. img.complete.html would also fail that one
assertion honestly: a subresource fetch is synchronous with the parse here (Runtime/Parsing/AGENTS.md), so
complete really can move inside the task that set src. update-media.html, adoption.html and
relevant-mutations.html are the source set's own siblings and are held back by the same missing bytes:
each names /images/green-2x2.png or its kind.

Three more are held back by a gap this browser has rather than by a missing environment, and
Dom/divergences.md carries a row for each. invalid-src.html and
null-image-source.html both wait for the error an fires, and the former DOM integration asks the resource loader for nothing when it selects no source, so there is no request processor to hang that event on. `non-active-document.html` asserts that an image in a document nothing is showing performs no load, and its `<template>` case fails here: the former DOM integration gives a template's contents no owner document of their own, so an inside one has a fully active node document and really is fetched. Its other two cases — a
DOMParser document and createHTMLDocument — pass, and the document is left out rather than vendored with
a NeedsTriage row, because it also needs a binary this corpus does not hold.

The two smallest suites, and `document.all` Copy Chapter

html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html and
html/obsolete/requirements-for-implementations/other-elements-attributes-and-apis/document-all.html are the
whole of what upstream asks about document.all, and all 43 of their assertions pass, with no exclusions.
Between them they cover HTML §4.13.2.3 — the supported names, the "all"-named elements, the named lookup that
answers a live HTMLCollection when several elements match, item(nameOrIndex), namedItem(name) and the
legacy caller, including that it is not a constructor and ignores its this — and ECMAScript Annex B.3.6's
[[IsHTMLDDA]] slot, which is what makes typeof document.all answer "undefined" and
if (document.all) take its else branch. Dom/AGENTS.md says which wrapper carries the slot and how the
override table selects it.

One document is vendored out of each directory, because a suite is a directory here and each of these two
is one. Their siblings are about other interfaces — HTMLFormControlsCollection, HTMLOptionsCollection,
RadioNodeList, DOMStringList and HTML's obsolete document colours — and vendoring one moves the census's
Documents and Tests columns, so it is a change of its own rather than a passenger on this one.

What the pseudo-classes suite says about this browser Copy Chapter

html/semantics/selectors/pseudo-classes/ is HTML §4.16.3's own suite: one document per selector, run
against a page's real selector engine rather than against a table of strings. 27 documents, 122 tests, 13
of which do not pass, and every failure is one of three bounded things the former DOM integration does — only one of which
is still its DefaultPseudoClassSelectorFactory. That is the reason the suite is here: the page owns
:target, :link/:visited/:any-link, :enabled/:disabled, :default, :open/:closed,
:valid/:invalid, :in-range/:out-of-range, :read-only/:read-write, :placeholder-shown,
:indeterminate, :focus/:focus-within, :active, :checked and :required/:optional
(Runtime/Parsing/PagePseudoClassSelectorFactory), and nothing until this suite arrived
measured any of them.

None of these three has a row in the cause table above, and that is by construction: the table counts the
six DOM suites, and every one of these is a failure of this suite alone.

Five of the eleven the suite arrived with are gone, and the two that are left of them are named for what
they now hold. The page owns :in-range/:out-of-range and :valid/:invalid — both ask HTML's
"candidate for constraint validation" question the former DOM integration folds into CheckValidity(), :in-range also
asks for range limitations, and a fieldset is decided from its descendants — and :read-only/:read-write,
:placeholder-shown and :indeterminate, which ask whether the attribute they are about applies to the
type state, answer for a <textarea>, and know about a radio button group and about a progress attribute
that is absent rather than empty. That retired 34 rows of this suite and one of
dom/nodes/Element-closest.html. Three type-change documents did not become green and moved instead:
their selectors answer correctly now and their remaining assertion compared a computed colour against a
literal. getComputedStyle now serializes color longhands as rgb(), so all three pass, and
RenderlessSelectorStyleTests independently checks the type changes and live cascade.

:focus is the sixth, and it needed the page rather than the predicate. the former DOM integration answers :focus and
:focus-within from IElement.IsFocused, a flag nothing in this package sets — its own DoFocus() assigns
neither that flag nor ActiveElement, which is why Events/FocusController is the page's focus model — so
the selector could not see a focus every event and document.activeElement already agreed about. The
factory now reads that model, and HTML's focusing steps stop being confined to the displayed document: an
element.focus() inside a child navigable takes the focus out of the page, which is exactly what
focus.html's last case asserts and what kept it passing while the other four did not.
:focus-visible is deliberately still the former DOM integration's and still matches nothing — Selectors §9.4 makes it a
decision about drawing a focus indicator, which a browser with no rendering cannot make — and
Dom/divergences.md records that.

And the last three predicates went with them, which leaves :dir() as the only selector cause in the
table above.
:active's five categories are four formal activation states — a keyboard notion this browser has no
key-held state for — and being actively pointed at, which is pure input: BrowserEventRealm.MousePressTarget
is already the element a trusted pointer press landed on and is cleared by its release, so the predicate is
that element, its ancestors, and the labeled control of a label among them. Nothing asks whether the
element is disabled and the standard does not either, which is the whole subject of active-disabled.html.
:checked stops answering for the historical <menuitem> and starts asking an input for its type state.
:required/:optional ask §4.10.5.3.4 whether the attribute applies, so an input outside its fifteen type
states is in neither class — which is what required-optional-hidden.html is about, and that document's row
moved to the color-serialization group above rather than turning green, exactly as three type-change documents did
before it.

checked.html is green now, and its last row was never a selector at all. Only two of that file's three
rows were the <menuitem>; the third sets option2.selected = "selected" in a single-selection <select>
whose option1 is already selected, and HTML §4.10.10
makes that setter ask for a reset — the select's selectedness setting algorithm, which leaves only the
last selected option selected. option.selected, selectedIndex, value and selectedOptions all reported
the same three-choice one-choice select, so no predicate could have decided it: HTMLOptionElement.selected
is a hooks setter now and Dom/HtmlSelectState owns the algorithm, the display size :open already needed
and §4.10.10's disabled option :disabled already needed. What HTML also runs on an option's insertion and
removal steps is still unrun, and Dom/divergences.md names it.

Four of the directory's files are not vendored and none of the reasons is a defect. autofill.html's two
assertions are test_valid_selector, which lives in /css/support/parsing-testcommon.js — a helper root this
corpus does not hold — so the file throws at file scope and reports nothing; indeterminate-radio-group.html
is a reftest and its -ref.html is the reference it is judged against; and the two .window.js files are the
glob every suite here has. checked-001-manual.html is covered by the lane's own -manual. marker.
focus-iframe.html is vendored, as a frame body: focus.html loads it to assert that :focus does not
match a focused element inside a frame.

What the DOM corpus says about this browser Copy Chapter

All 43 assertions in the eight dom/collections/ documents pass, with no exclusions.
HTMLCollection-as-prototype.html now permits an inheriting receiver to assign its own property over
a supported name; the collection's named reads remain live.

Four collection algorithms are the standard's here rather than the former DOM integration's, because the former DOM integration's own
answer is reachable through no seam: getElementById refuses the empty key DOM §4.9 says no element can
have, getElementsByClassName parses the ordered set and folds ASCII case only in quirks mode,
NodeList.item answers null past the end the way an indexed getter must, and HTMLCollection.namedItem
takes the first element in tree order whose ID or HTML-namespace name is the key. Dom/divergences.md
has the upstream half of each, and Dom/AGENTS.md says which override list carries it.

dom/nodes/, dom/collections/, dom/lists/, dom/traversal/, dom/ranges/ and html/dom/ are the DOM
standard's own suites and HTML's DOM half — the corpus every other suite in this lane is written on top of.
Across the six of them there are 226 documents and 65,228 tests, and 24 of those tests do not pass.
Those three figures are live and checked against the census. They arrived together as 207 documents and
5,247 tests with 1,532 not passing; those arrival figures are historical and deliberately not re-derived.

The table names each distinct cause test by test. Its two numeric columns and its order are generated from the
same browser-lane run as the census: a cause is a named group in WptBrowserExclusions.Causes, and each row
carries that name in an HTML comment this page does not render. The prose remains hand-written.

JINT_WPT_BROWSER_CENSUS=1 checks the table and =update rewrites the numbers and order. Every failing test
must belong to exactly one cause, and every cause that reaches these six suites must have exactly one row.
Unlike the census's Not passing ceiling, both columns are equalities: a cause growing or shrinking means the
table needs to be regenerated.

The XML-document cause is gone, and it was four different things. It arrived as a scope decision —
"a page here parses HTML, the former DOM integration builds no XML document" — and by the time it was re-measured that
sentence had stopped being true: a frame parses XML (#3873),
XMLDocument has its interface (#3893), and
createDocument registers its own table. Running its seven documents one at a time
(#3766 is the history) split its 346 rows four ways.
190 were metadata this package owns and now produces: location is null for a document with no
browsing context, characterSet answers the Encoding Standard's name with charset and inputEncoding
beside it, contentType is what the algorithm that made the document gave it, and createElement on a
document that is not an HTML one keeps the name's case. 137 are not about XML documents at all —
processing-instruction-attributes.html exercises the attribute surface now specified by
DOM §4.13, plus HTML processing-instruction
parsing. Its earlier description as an unstandardized proposal is obsolete. The attribute-map implementation
and element serialization fix removed 100 failures; native HTML PI parsing in
#4207 resolves the remaining 20 HTML parser assertions
tracked by #4098. The current cause contains ten
PI-dependent assertions whose ill-formed PI-only XML fixture expects a preserved PI before the error
tree, contrary to HTML §8.5.1. These are AssertsWhatNothingRequires, not engine debt; name-validation
assertions that also pass on the parsererror element remain unexcluded. 42 were the name refusals the table already named, reached three times each; #3950 made them pass and took the rows out. The rest are
the former DOM integration's: node equality compares base URLs, a live range is not adjusted across documents, and the
HTML element factory lower-cases a local name it is handed.

NeedsXmlDocuments has no rows left at all. The last thing it named was one the former DOM integration mapping:
application/xhtml+xml reached the HTML parser, so the two XHTML fixtures Document-createElementNS.html
and Document-createElement.html frame came back wrapped in a second <html> skeleton and all 244
rows died on the trailing newline that adds, before either reached the member it is about. A page picks its
own parser from the response's content type now, for a frame and for a navigation alike
(Jint.Browser/Runtime/Parsing/AGENTS.md), so all 244 of
them pass and neither file carries a single exclusion — #3950
having already taken out the name-validation rows that would otherwise have been the XHTML half's share. The
category was read for a long time as "the former DOM integration cannot be made to do this", and what was actually
unreachable was a second document factory; choosing the parser was never the same question. The member stays for the one
thing an XML document here still cannot do — run a script — which is also why no .xhtml document in
the not-vendored table below becomes vendorable: each of them loads testharness.js through a
<script src> and would report nothing.

html/dom/historical.html is the file that tells three different things apart, and "remove it" is the wrong
answer for two of them. HTMLAppletElement, HTMLTableDataCellElement and HTMLTableHeaderCellElement are names
the standard removed: the first was never declared here, and the other two were the former DOM integration's split of
HTMLTableCellElement into two interfaces HTML does not have, so both are excludedInterfaces rows now and the
one member the split carried — scope — comes back as a reflected row on the interface HTML puts it on.
document.applets is the opposite: HTML §16.3 keeps it and defines it to answer an HTMLCollection whose
filter matches nothing, which is a member the binding had to gain rather than lose. And <applet> is neither —
the element still parses, and takes the HTMLUnknownElement every unlisted HTML name takes, which the former DOM integration
cannot say because it builds a real HtmlAppletElement. Four of the file's six failures went with those, and a
fifth with document.all becoming a real HTMLAllCollection, whose supported names take a name attribute only
from one of the fourteen "all"-named elements and applet is not among them. The one that is left is somebody
else's cause — cssFloat is not one of the ten properties ResolvedStyle answers an initial value for — so the
row this file used to have is gone rather than shrunk.
Half of the Range row is gone, and that half was never about Range.
Range-in-shadow-after-the-shadow-removed.html takes its shadow-root mode from
<meta name="variant" content="?mode=open"> and its closed sibling, and the lane used to serve the bare
path — so mode was null, attachShadow({mode: null}) raised the TypeError WebIDL's enum conversion
owes a browser too, and both of the file's tests failed before either reached a Range at all. Running a
document once per declared variant is what removed them: four assertions over two cases now, all passing,
nothing excluded, and what is left under that cause is the Range-adopt-test.html pair, which really is
the bookkeeping. It is worth naming as a shape — a share of a cause that turns out to be the lane
rather than the engine, whose fix is therefore a change to how a case is enumerated and not to the
subject the document was about.

All ten of HTML's reflection documents are cases, and nine of the ten pass whole
(#3770). HTML §2.6.1's reflection algorithms are
Jint.Browser/Dom/ReflectedAttribute.cs and the members that take them are overrides.json's reflected
list, so reflection-misc.html (4,877 assertions, 1,866 of them failing before), reflection-text.html
(10,202, 3,360 failing before), reflection-sections.html (5,604, 2,189 failing before),
reflection-tabular.html (6,116, 3,552 failing before), reflection-forms-weekmonth.html (1,579, 420
failing before), reflection-embedded.html (8,922, 3,774 failing before), reflection-grouping.html (5,358,
2,006 failing before), reflection-obsolete.html (2,621, 1,483 failing before) and reflection-forms.html
(8,271, 2,160 failing before) pass with nothing excluded, and reflection-metadata.html (3,110, 1,218
failing before) has one cause left — and it is not reflection. 22,028 of 56,660
assertions failed when the suite was measured; 16 do now.

191 rows did it, and the first fifteen were mostly the global attributes every element carries —
dir, lang, tabIndex, autofocus, inputMode, enterKeyHint — which is why text needed only eleven
rows of its own for 3,360 assertions. The rest are element-specific, one reflected row each.
metadata took seven of those —
link's as, crossOrigin, referrerPolicy, charset and target, and meta's media and scheme —
plus one member that is deliberately not reflection at all: nonce answers HTML §2.5.3's
[[CryptographicNonce]] slot, whose setter writes the slot and leaves the content attribute alone, so a
script[nonce] selector cannot read back a nonce a header-delivered policy issued
(Jint.Browser/Dom/CryptographicNonce.cs).

sections took thirteen and cost the row model two things it could not say. Six of its members are on
Document and reflect an attribute of another element — §3.2.6.4's document.dir off the html
element, and §16.3.3's fgColor, linkColor, vlinkColor, alinkColor and bgColor off the body
element — so a row names a target now, and a document with no such element reads exactly as an absent
attribute and does nothing on setting, which is what the standard says of dir. Ten of them are
[LegacyNullToEmptyString], where el.text = null writes "" and not "null"; that is a flag on the
DOMString row rather than a fourteenth algorithm, because the getter is unchanged.

obsolete took eight, all on <marquee> — and found one defect in the shared implementation that every
unsigned reflected integer had: HTML says a value outside the range 0 to 2147483647 writes the attribute's
default, and WebIDL's unsigned long conversion is modulo 2³², so el.hspace = 4294967295 really does
arrive as that number rather than as −1. The setter wrote it verbatim. Eight rows of obsolete found it and
col.span, td.colSpan, input.size and textarea.cols would all have carried it.

tabular took thirty-nine, the largest table of the seven and the first with a clamped unsigned long in
it: col.span and colgroup.span clamp to [1, 1000], td.colSpan and th.colSpan to the same, and
rowSpan to [0, 65534] — three ranges, each with a default of 1, none of which any CLR signature carries.
It also needed one skip: the former DOM integration splits and into two interfaces HTML does not have, and
the header cell's own scope shadowed the reflected HTMLTableCellElement.scope, so answered the raw attribute value while answered the enumeration.

forms-weekmonth took eleven, all on , and one of them is HTML's only exception to URL reflection: **`formAction` answers the element's node document's URL when the content attribute is missing or empty** (§4.10.18.6), which is what a form posting to itself reads. `form.action` is the other member with that rule and the row model can say it now. Two more are 's width and height, whose getters are the
rendered image dimensions and are not reflection at all — but whose setters are, in as many words, so what
the rows fix is the half that is. Both rows still take the whole accessor pair, and deliberately: this
package renders no image, so the getter answers the content attribute either way, and answering it through
HTML's rules for parsing non-negative integers rather than through the former DOM integration's DisplayWidth is the
difference between width="-5" reading 0 and reading −5 out of an unsigned long.

forms took fifteen more — the rest of the form controls, and the two remaining numeric shapes: textarea's
cols and rows are limited unsigned longs with fallback (a zero or out-of-range set writes 20 and 2
rather than throwing, which is what separates them from input.size, where it is an IndexSizeError), and
progress.max is a limited double, whose setter declines to write at all when the value is not greater
than zero. select.size defaults to 0 where input.size defaults to 20, and button.formMethod has a
dialog keyword input.formMethod does not — three facts about three members that no CLR signature carries
and the reflected list has to state.

Six more rows finished it, and they are the first that reflect only a setter. <meter>'s value, min,
max, low, high and optimum are the case a whole replacement would have made worse: their getters are
HTML §4.10.14's own algorithm — an absent max is 1, optimum is the midpoint, the value is constrained to
the range — which the former DOM integration implements and no reflection type can express, while their setters are plain
§2.6.1 reflection and were writing Double.ToString(InvariantInfo) where HTML wants "the best representation
of the number as a floating-point number", which is ECMAScript's Number-to-String. So the row model grew a
setterOnly flag: the entry replaces the setter and the generator keeps the projected getter's body, and it
refuses — as a diagnostic, not as generated code — a row that asks for it where there is no projected getter
to keep or where a getter hook has already claimed the read.

embedded took the last fifty, over ten interfaces, and was the largest single table: 's twelve, `<object>`'s twelve, 's nine, and the media elements' preload, crossOrigin and loading on
HTMLMediaElement rather than on <video> and <audio> separately, which is where HTML puts them.
track.kind is the suite's clearest case for stating both defaults — its missing value default is
subtitles and its invalid value default is metadata — and preload's are implementation-defined among
its three states, which is why the row picks auto and the corpus asserts membership of an array rather than
one value.

The one cause left is not reflection, and it is the dependency. Two others were, and both are gone: four
obsolete elements — <dl>, <dir>, `` and <frame> — get an interface of their own from HTML and a
plain HTMLElement from the pinned assemblies, so there was nowhere for compact, color, src and their
kind to be reflected onto, and 506 rows named the tests. DomManualInterfaces declares all four by local name
now, the way it already declared HTMLFrameSetElement — one shape and one prototype chain per interface
over the same the former DOM integration element — so reflection-grouping.html and reflection-obsolete.html pass whole,
and the divergence table records what the pinned assemblies are still missing. <meter>'s six setters were
writing a double with .NET's number format, so -0 kept its sign and an exponent was 1E-10 where HTML
wants ECMAScript's 1e-10 — three values per member, eighteen rows, and a whole reflected row would have
been a regression because those getters are HTML §4.10.14's and are right; setterOnly is what took the
half that was wrong, and reflection-forms.html passes whole. What is left is <style>'s media, which
cannot be written at all when the value is not a media query the former CSS integration can parse — the exception comes
out of Element.setAttribute itself, through the attribute observer the former DOM integration core registers, where Media
Queries §2.1 requires an unparseable query to be replaced by not all. Those 16 rows are the only failures
this lane's html/dom/ figure gained, against 51,783 assertions it did not have before.

Four documents did not terminate at all, and that was the finding this campaign put first.
TreeWalker-currentNode.html, TreeWalker-previousNodeLastChildReject.html, TreeWalker-traversal-reject.html
and TreeWalker-traversal-skip.html each spun forever: the former DOM integration's TreeWalker.ToPrevious never advanced the
sibling it was reading and never climbed to a parent, so previousNode() looped the moment the previous
sibling was not accepted outright — a filter answering FILTER_REJECT or FILTER_SKIP, or a currentNode
pointed outside the root beside a node whatToShow excludes. Nothing in this lane could bound that —
BrowserOptions.MaxTaskDuration is deliberately infinite, the driver's own 30 s deadline cannot interrupt a
page thread that never yields, and a node whatToShow excludes is FILTER_SKIP without the page's filter
being called, so the loop never re-entered the engine for a constraint to fire in — which is why an embedder
should read #3765 as a denial of service rather than as a
conformance gap. DOM §6.1's seven traversals are Jint.Browser's own now
(Dom/Views/DomTreeWalker, and its file argues each loop's termination); the four documents are cases, all
seventeen of their tests pass, and TreeWalker-basic.html's "Walk over nodes." passed with them.

And two missing members were worth thirty-six documents. dom/common.js is the fixture builder the
whole of dom/ranges/ and half of dom/traversal/ load; it calls document.createCDATASection on a
new Document() and document.implementation.createDocument two lines later, both before a single
test() runs, so twenty-four Range documents, three traversal documents and nine more under dom/nodes/
and dom/events/ reported nothing at all. Both members exist now
(#3766), their not-vendored rows say so, and vendoring
the thirty-six is a change of its own: it moves this table's Documents and Tests columns, which the change
that fixes an engine deliberately does not — the same standing the four dom/events/ documents that were
waiting on document.createEvent already have.

Adding createDocument raised the ceiling, deliberately and once. DOMImplementation-createDocument.html
builds its own table of 434 cases inside its first test, and the builder called the missing member — so
the file reported two tests and the other 432 were never registered at all. They are registered now,
348 of them fail, and dom/nodes/'s not-passing figure went from 2,000 to 2,333 with them. That is what
JINT_WPT_BROWSER_CENSUS=update-raising-the-ceiling is for, and it is used here for exactly that: the
failures are not new, only newly counted.

What is not vendored, and why Copy Chapter

WptBrowserExclusions.NotVendored is the enforced list; the shape of it is worth knowing because it is
different from the engine lane's. Almost every row is a document that cannot produce a per-test report at all
— a harness ERROR or TIMEOUT — which is what puts it there rather than in the exclusion table: a harness
error covers the whole file and no per-test exclusion can name it. The rest are the globs upstream's own
markers and this lane's directory rule earn, and the helper files of documents nothing here runs. They fall
into twenty-nine groups; the counts are rows rather than files, since several are globs. Ninety of
the rows belong to the six DOM suites, which is what a corpus about every member of every node interface
costs: half of them are one member reached at file scope. A twenty-ninth answer is not in this table at
all: WptBrowserExclusions.FrameBodies names the documents that are vendored and served and never run,
which is what a fixture sitting beside the cases that load it needs — see below.

A document can also be vendored, served and never run. WptBrowserExclusions.FrameBodies is that
third answer, and it exists because a document directly under a suite is a case — WptCorpus.BrowserTestFiles
never descends, so a helper lives under resources/ or support/ and a case does not. Upstream does not
always agree. ParentNode-querySelector-All-content.html sits beside the three documents that load it into a
frame and is a fixture with no testharness.js in it, so the only two answers this lane had were to run it
and time out or to leave it out of the corpus and lose every case that loads it. Now it is vendored, served
and not a case, and the table is held from both ends like every other one here: a row must name a document
the corpus really holds, directly under a suite this lane claims, and no row may also be a NotVendored
pattern — a path cannot be absent and served at once. It takes no minimum-test entry and appears in no census
column, because neither counts anything about a document that reports nothing; what holds it to its job is
the three cases that load it, which fail loudly if the frame they wait for never arrives.

There are two rows now. focus-iframe.html is the second: focus.html frames it and asserts that
:focus does not match a focused element inside it, which is a document that has to be served and must
not be a case of its own.

And that is what let the selector table in. Element-matches.html, Element-webkitMatchesSelector.html
and ParentNode-querySelector-All.html are the whole of wpt's Selectors-API suite, run three times over —
through matches(), through its prefixed alias, and through querySelector/querySelectorAll in five
contexts (a document, an in-document element, a detached element, an empty element and a fragment). They were not vendored for
two reasons at once: the frame body above, and the fact that a frame had no document to be
(#3771). Both are answered, and the three documents bring
3,313 tests, of which 3,297 pass — and dom/nodes/ grows from 4,802 tests to 8,115. The 16 that do
not pass are bounded to the patterns in the exclusion table, and all 16 are in the third document: the
selector-error contract differences are gone. A relative selector, an undeclared namespace prefix at any
depth and an attribute selector closed by EOF are all DomSelectorText's now
(#3946, and Jint.Browser/Dom/divergences.md has a row
for each), so Element-matches.html and Element-webkitMatchesSelector.html pass entirely. What is left is
the ::slotted() functional pseudo-element, whose native parser dispatch is a private frozen dictionary
with no registration point. The empty namespace prefix now uses DomSelectors: a token adapter and a
public predicate factory composed with the native parser and matcher. They are NeedsTriage, for the reason that category
exists: the change that first runs a suite is not also the change that moves the engine. The older branch
named 518 failures; current main fixed 390 of them before the corpus landed, and the two-sided exclusion
check removed every stale row rather than preserving that historical result.

One of them was the machine's answer rather than the browser's, and that is fixed rather than excluded.
:lang(en) on an element with no inherited language matched on a host whose culture is English and did
not on one whose culture is invariant — the Windows and the Linux CI leg exactly, so four rows of this
document passed on one and failed on the other and no exclusion could name them on both. the former DOM integration resolves
such an element through the browsing context's culture, and the context had none, so it took
CultureInfo.CurrentCulture off whichever thread was parsing. ParserDriver gives the context the
engine's culture now (Options.Culture, which itself defaults to the current culture, so nothing moves
for a host that sets none), and this lane pins its own to the invariant culture — a gate whose answer depends
on the runner's locale is not a gate. All four pass everywhere now; scoping the exclusion to an operating
system would have encoded the coincidence instead of removing it.

The testdriver.js group is gone, which is what recording it by name was for. Campaign item C4 mapped
upstream's automation API onto the same InputDispatcher the Input domain reaches, through the
testdriver-vendor.js slot upstream ships empty for a vendor to fill (AGENTS.md has the rules). Its seven
documents were then re-examined one at a time, and five are cases now —
Event-dispatch-redispatch.html, focus-event-document-move.html, handler-count.html,
no-focus-events-at-clicking-editable-content-in-link.html and pointer-event-document-move.html,
fourteen tests between them, all passing, none excluded — fourteen rather than ten because
handler-count.html declares three variants and is three cases. Two still cannot report, and neither
reason was ever the driver's:
Event-dispatch-on-disabled-elements.html spends five of its nine tests waiting for CSS transition and
animation events on a disabled control, so it never completes and never reaches its testdriver-driven test at
all; and click-on-absolute-pseudo.html reads event.pseudoTarget and element.pseudo('::after'), which
need a pseudo-element model. Both are a rendering rows now. The mapping found no new defect, which is
the outcome running documents through an existing dispatcher should have.

The customElements row that used to sit in the "a name this browser does not have" group has gone the same
way: window.customElements exists, and EventTarget-add-listener-platform-object.html is a case again.

What runs, and what it costs Copy Chapter

The whole lane is about forty seconds — one WptServer, one Browser, and a fresh BrowserContext and
Page per document. It was ten seconds before the DOM suites, which multiplied the documents by two and a
half and the assertions by four. No case comes within a factor of three of the driver's 30 s deadline,
and keeping that true is why the six NodeList-static-length-getter-tampered* documents are not vendored:
the largest of them took 18.8 s idle and crossed 30 s on a loaded machine, and a case whose outcome depends
on the machine is exactly what the census exists to keep out. Nothing in it waits on a real clock except upstream's own harness timeout, and no document
reaches it: every case reports, which is the property EveryVendoredDocumentIsAccountedFor and the
minimum-test table together keep true.

Overview (`tools/browser-comparison/README.md`) Copy Section

Controlled offline browser comparison

This tool follows #3575 X4. The original
#3907 smoke/raw-diagnostic harness is extended under
#3930. One PuppeteerSharp client applies identical offline
workloads and independently expected checksums to Jint.Browser, Chromium, and Lightpanda.
No Lightpanda source is read or copied.

A working harness is not a completed benchmark campaign. X4 remains open until the complete idle-accepted
paired run and its scoped conclusion are published. No timing result is included here.
Read the benchmark instructions before measuring or quoting numbers.

Correctness first Copy Chapter

Build the Jint executable in Release, copy example.json, and fill in the already installed browser paths.
The harness never installs or downloads a browser. Record the Lightpanda release asset identity and verify
its digest before running the binary. Official nightly assets currently include macOS aarch64 and x86_64;
macOS 13 or later is supported.
The nightly URL is mutable, so a URL alone
is not a version pin. LIGHTPANDA_DISABLE_TELEMETRY=true is set for owned Lightpanda processes.

dotnet build Jint.Browser.Tool/Jint.Browser.Tool.csproj -c Release -f net10.0
python3 tools/browser-comparison/measure.py --config /absolute/path/config.json \
  --output /absolute/path/new-verification-directory

Verification freshly builds the Release harness and runs all five workloads in both lanes on every configured
adapter. It exports exact HTML, JavaScript, expected results, identity and provenance. Every result has
Measurements: null; no elapsed/CPU/memory fields are emitted as measurements. Missing binaries, unsupported
behavior, mismatched checksums and cleanup failures fail visibly. One adapter is sufficient for verification.

The underlying one-row CLI remains useful:

dotnet run --project tools/browser-comparison/BrowserComparison.csproj -c Release -- \
  --config /absolute/path/config.json --smoke

workload, lane, warmupCount, and iterations select a row. Cold requires one iteration on a new browser
and page; warm first executes five unmeasured repetitions of that row, then ten measured repetitions in the
collector. Each repetition navigates to a fresh copy of the fixture. Warm means a warmed browser/runtime,
not retention of a mutated DOM across iterations. No sibling workload warms another row's state.

The FormData(form) compatibility failure originally found by the unchanged event-form workload
(#3931) is resolved. The collector and correctness smoke
landed in #3941. The remaining X4 acceptance work is an
empirical Jint A/A calibration and the complete three-browser comparison on an idle-accepted Linux host
with delegated cgroup v2, including the scoped hosted-VM route below, followed by independent
reproduction, retained evidence and a scoped conclusion in
#3930.

These cover the campaign's extraction, mutation, interaction and local asynchronous automation use cases.
They do not represent rendering, Internet latency, arbitrary production sites, or every framework.

Ownership and measurement boundaries Copy Chapter

Owned Jint, Chromium and Lightpanda adapters launch new processes for every row. Chromium receives a new
profile; Lightpanda uses its documented serve --host 127.0.0.1 --port 0 endpoint announcement. Startup,
connection, page work, teardown and failure cleanup have bounded waits. Both diagnostic pipes are drained into the preserved per-launch stderr log.
The configured command and effective arguments/settings are recorded. Teardown attempts browser close and
records whether forced process-scope termination was needed; every owned descendant must exit.

A Lightpanda configuration with endpoint instead of executable borrows a local endpoint and may optionally
name its processId. Borrowed adapters disconnect without terminating that process. They remain available
for smoke/raw diagnostics and are rejected by the comparison gate.

Complete installation/runtime manifests and workload export happen before the idle checks. A single batch
hashes the union of every configured adapter and harness installation plus system library roots once.
Each adapter retains its own executable, arguments and version label, with the same conservative superset
of dependency hashes. Coverage metadata explicitly identifies the batch union; analysis requires identical
union contents for every adapter and the harness. An independent fresh batch after collection hashes the
whole union again; there is no cache across phases, and changed dependencies invalidate the entire run.
The batch setup deadline is 1,800 seconds, bounded separately from measurement: hosted diagnostics showed
steady progress through 130,796 files / 9.47 GB at 870 seconds before the former 900-second identity limit.
Canonical traversal remains serial; a bounded queue feeds at most four synchronous hashing workers
only during setup. This overlaps independent file reads without dropping paths or reusing old hashes.
Any traversal or worker failure rejects the entire snapshot. Progress records retain active read paths
as well as completed file/byte totals. This addresses the variable cold-filesystem throughput observed
in hosted run 35729896926, which reached 140,793 files / 10.55 GB before the same setup deadline.
No measurement-window, idle-check or accounting deadline changes.
The Linux manifests include complete system library trees to cover native loaders, dynamic libraries,
child helpers and runtime snapshots, plus configured dependencyRoots for additional installations.
The one declared exclusion is canonical /etc/ssl/private and its descendants: this private-key
store is reached by Ubuntu's /usr/lib/ssl/private directory link, but is not a library installation.
Its contents are never enumerated or opened. The manifest records the exact boundary and reason,
and analysis rejects absent or broadened exclusion metadata. Explicit executables, file arguments or
configured dependency roots within that boundary are refused. Native helpers and external library
symlinks remain covered, and every other missing/unreadable file still fails visibly.
Symlinks are resolved before checking the boundary; dynamic-loader overrides are rejected.
On macOS, application bundles are hashed but the OS shared runtime remains diagnostic-only.
Binary hashing never runs between an accepted idle check and its browser launch. Stage sums can differ from the continuous total
because scope snapshots and observer shutdown are explicit overhead. Cold results are not a whole-application
startup measurement; warm rows are not a claim about persistent browser caches or JIT convergence.

Whole process accounting and supported platforms Copy Chapter

Gate mode requires an already delegated Linux cgroup v2 root with CPU and memory controllers enabled.
The host administrator supplies an empty delegation; the tool does not alter parent cgroup policy or elevate
itself. The kernel must provide cpu.stat, memory.current, memory.peak, cgroup.kill, and population state.
Each launch receives a new UUID child scope. The browser starts only after entering that scope, and all of its
descendants remain accounted even after reparenting or exit. The client, fixture server and observer remain
outside it. Shell startup and the membership write occur before scope entry and are excluded from the
cgroup counters; browser exec and the remaining shell work after entry are included. The launch wall clock
also includes that initial shell startup.

PID/start-time observations are fallible diagnostics. The collector rechecks start time and membership,
records observed identity changes, missing fields and read failures, and labels successful observations
non-atomic. Such misses do not invalidate the independent kernel CPU/memory counters or imply that a process exited.

CPU is the scope's cumulative microsecond counter, including exited children. Memory is charged cgroup
usage, which can include page cache and kernel charges; it is not portable RSS. The launch, preparation, page-work and teardown peaks are each the maximum observed simultaneous
scope usage sampled continuously every 10 ms, with explicit stage labels, timestamps and boundary samples.
The kernel's lifetime scope peak is recorded separately. Never sum individual PID peaks, subtract lifetime
peaks, or compare different backends as though they measured the same memory. Sampling can miss transients;
the observer itself adds overhead outside the browser's scope.

The portable root-PID snapshots remain labeled diagnostics and are never substituted for missing tree
counters. Native macOS Lightpanda availability does not imply that complete accounting is available there.
Container/VM results must identify that host boundary; do not treat an idle guest as proof its physical host
is idle. A dedicated idle physical host gives stronger isolation; hosted-VM campaign evidence must retain
that limitation, pass the same guards and accounting checks, and independently reproduce.

Controlled collection and analysis Copy Chapter

python3 tools/browser-comparison/measure.py --config /absolute/path/config.json \
  --output /absolute/path/new-gate-directory --measure --rounds 6 --launches 3 \
  --scope-root /sys/fs/cgroup/already-delegated-comparison-root
python3 tools/browser-comparison/analyze.py /absolute/path/new-gate-directory > analysis.json

The driver requires all three owned browsers, a clean committed checkout, and exact identities. It freshly
builds Release, exports workload bytes, requires a fresh successful real kernel accounting validation, then uses the same blocking idle validator source as BenchmarkDotNet
(40% of one core, up to 45 seconds settling). A second Linux aggregate CPU check closes process-enumeration
blind spots. Checks bracket every launch. An idle refusal invalidates the collection and is preserved;
JINT_BENCH_SKIP_IDLE_CHECK is rejected. Unsupported platform/counter conditions fail before measurement.
This does not continuously monitor interference inside an individual workload; that limitation remains in
the evidence alongside the recorded physical-host or hosted-VM boundary.

The Linux topology behavior matches the repository's unpinned fallback. No power plan is changed; fixed-clock
overrides are rejected. Production tiering/PGO stays enabled. Jint uses blocking workstation GC; other engines
retain their own GC. Inherited runtime tuning overrides are rejected rather than silently changing a lane.

Six rounds cover all six orders of the three browsers, with three independent launches per row per round.
This balances middle positions as well as first/last order. Execution is serial. The analysis first takes each
browser's median launch value within a round, then forms paired round percentage differences. It reports their
median and a 95% percentile bootstrap interval over paired rounds (10,000 resamples, seed 3575), preserving
all pairs. These are pointwise exploratory intervals, without correction for multiple comparisons. Launches are not treated as independent rounds. An interval crossing zero has unresolved direction;
an untouched control establishes the experiment's noise floor. There is no control subtraction.

Analysis rejects missing/duplicate/reordered pairs, changed binary/dependency identities, mismatched workloads,
failed idle checks, digest mismatches, incomplete teardown, regressing/missing counters and invalid memory
samples. The artifact directory keeps the configuration, source/binary hashes, actual Lightpanda version
output and release identity, runtime/host details (including Linux CPU topology, memory and clock policy), schedule, idle logs, per-launch raw JSON and errors.
manifest.json records each planned row before it starts and is updated atomically as rows finish.
A per-launch lifecycle journal records every stage and a structured terminal failure/cleanup/accounting
verdict. The collector separately persists its own scope-cleanup attempt, even if the runner times out. A failed or partial
manifest is never accepted by analysis. Preserve the whole directory, not just a rendered table.

Validation and calibration Copy Chapter

dotnet test --project tools/browser-comparison.Tests/BrowserComparison.Tests.csproj -c Release
python3 -m unittest discover -s tools/browser-comparison -p 'test_*.py'
JINT_BROWSER_COMPARISON_CGROUP_ROOT=/sys/fs/cgroup/already-delegated-comparison-root \
  python3 -m unittest discover -s tools/browser-comparison -p test_linux_accounting.py

The kernel leg verifies a CPU/memory child whose parent has exited and retained counters. The Release
adapter tests exercise the actual owned-process cleanup for cancellation, timeout, checksum assertion
and early launch failures, including reparented children in the delegated Linux CI leg.
It reports a skip when delegation is absent; that is not a passing kernel validation. Synthetic tests cover
scheduling, counter failures, pairing and confidence intervals without supplying performance evidence.
An empirical A/A calibration is available by adding --calibrate jint (the configured adapter name) to
the gate collection command. It runs two identical owned configurations through the same collector and
analysis. Calibration must run on the same machine (the same VM for a hosted run) before trusting small deltas; this
repository does not claim that synthetic zero-difference fixtures constitute that calibration.

Manual hosted-runner feasibility Copy Chapter

.github/workflows/browser-comparison-hosted.yml offers verify, calibrate, and compare dispatches
on ubuntu-24.04, with a 360-minute job ceiling and no parallel measurement jobs. This is a hosted-VM
feasibility experiment, not evidence that its physical host is dedicated or idle. An accepted guest idle
check cannot observe noisy physical neighbors. Keep this boundary alongside any conclusions. Campaign
acceptance also requires an independent repeat under the agreed criteria; a single successful hosted run
does not establish reproducibility or guarantee that a later runner will qualify.

verify installs the reviewed hosted-pins.json assets and runs correctness only. calibrate runs Jint
A/A through the existing six-round, three-launch collector. compare first performs that calibration,
then the full three-browser collection serially on the same VM. Inspect the calibration intervals and
untouched controls before interpreting differences; a completed calibration is not an automatic noise-floor
acceptance verdict. A refusal or timeout is feasibility evidence, never a timing result. No gate is weakened,
no service unrelated to this run is disabled, and no physical-host control is claimed.

The optional browser_pins JSON dispatch input replaces the reviewed pins in full. Full Chrome for Testing
must have a versioned official linux64 ZIP URL, exact version and independently reviewed archive SHA256.
Lightpanda must have an official release asset API URL, matching asset ID and SHA256 of the executable.
The checked-in pins were resolved before measurement; a mutable nightly alias is never sufficient.
The default Lightpanda asset is the Linux x86_64 binary from
stable release 0.4.1.
The earlier pinned nightly asset was removed upstream before calibration; changing the pin requires
fresh correctness verification, and its results must not be mixed with the earlier binary's evidence.
setup_hosted.py verifies downloaded bytes before execution, preserves download/executable hashes,
records actual version output, and creates the collector configuration outside the clean checkout.
No Lightpanda source is accessed. A removed asset or digest mismatch fails without resolving a replacement.

Ubuntu's user-namespace restriction needs a scoped allowance for downloaded Chrome. The workflow uses
Chromium's documented AppArmor option 2,
with an exact canonical executable path instead of a glob. A run/attempt-specific root-owned profile
allows userns for that executable; the path alphabet rejects AppArmor patterns and variables.
Chrome's sandbox stays enabled, no global sysctl is changed, and no unrelated profile is reloaded.
The generated policy, its hash, and load/removal logs remain in the artifact. Cleanup removes only the
profile installed by this run, after stopping its measurement service. No AppArmor setup runs locally.

Only the measurement invocation runs in a transient systemd unit. Administrative creation delegates CPU and
memory controllers to that unit; DelegateSubgroup=controller keeps the unprivileged collector out of the
empty parent. run_hosted.sh enables controllers only in its own delegation and creates the empty measurement
root there. The unchanged collector still creates a fresh child scope per owned browser launch and runs
its real kernel validation. Unit termination cleans only that invocation's descendants. No collector code
acquires elevated privileges or changes a parent cgroup policy.

Always-uploaded artifacts include dispatch pins, runner image and source identity, browser archives/binaries,
setup manifest, build and driver logs, full calibration/comparison directories, accepted analysis or partial
failure evidence. Retention is 30 days; retain the artifact independently before using it for campaign closure.
The Python runner, idle audit, library preflight and setup rejection tests run in comparison CI
without downloading browsers or changing host packages. The Linux accounting test skips in this
first pass; the delegated-cgroup CI step runs it separately:

PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tools/browser-comparison -p 'test_*.py'

The hosted image 20260907.300.1 contained three dangling LLDB18 Python library links, all owned by
python3-lldb-18; strict system-library hashing correctly refused verification. The setup preflight inventories
all dangling links and installed package versions. It permits only those exact paths, targets and ownership,
then simulates removal of the unused python3-lldb-18 package without autoremove. The removal set must be a
subset of python3-lldb-18, lldb-18, and lldb, contain the defective package, and install/configure nothing.
The same package-manager removal is then applied, actual package changes must match the simulation, and a
fresh inventory must contain no dangling links. Unknown defects fail before mutation. This is recorded setup
before binary manifests or measurements; it neither skips library hashes nor changes the collector.
library-preflight/ retains link inventories, package versions, apt logs and the terminal repair verdict.
The workflow's inspect phase (or the helper's --inspect) records evidence without any package mutation.

Hosted idle-category audit (diagnostics only) Copy Section

The idle-audit workflow phase samples the unchanged two-second aggregate /proc/stat guard
continuously for 30 minutes on a fresh hosted VM. It skips .NET setup, library repair, browser downloads,
AppArmor setup, builds, calibration and comparison. Every flushed JSONL observation retains the eight
raw start/end counters, category tick deltas, and each category's contribution to percent of one core.
Guest counters are already included in user/nice; idle and iowait contribute zero, while steal remains busy.
The existing 40% acceptance boundary and elapsed-time arithmetic are unchanged.

The always-uploaded artifact includes all observations and a diagnostics-only summary of refusals and
category totals/maxima. An accepted observation or completed audit does not accept any benchmark,
calibrate a noise floor, or establish physical-host isolation. Failures retain observations already written.

Overview (`tools/cdp-histogram/README.md`) Copy Section

CDP client handshake histogram

What does an automation client actually send? Not what the protocol describes, and not what a
compatibility table claims — what Puppeteer, PuppeteerSharp, Playwright, Playwright for .NET and the Chrome
DevTools frontend put on the wire when they drive a real Chrome through one ordinary scenario.

This tool answers that by recording it. It launches Chrome, puts a man-in-the-middle proxy in front of its
DevTools endpoint, points each client at the proxy, walks all of them through the same twenty-five step
scenario, and writes one file per client plus a cross-client matrix into
tools/devtools-protocol/handshakes/. Those files are the
implementation manifest for Jint.DevTools and Jint.Browser: a method that appears in the matrix is a
method some client will call, and a method that appears in the minimum must-answer set is one nothing
works without.

The results are checked in. Re-recording is a deliberate act — a client release changes them.

Running it Copy Chapter

cd tools/cdp-histogram
npm install                 # also downloads Chrome for Testing (puppeteer's postinstall)
node run-all.mjs            # records every client, then rebuilds matrix.md

Other entry points:

node run-all.mjs --only=playwright-node,puppeteer-node   # a subset
node run-all.mjs --skip=devtools-frontend                # everything but the best-effort capture
node run-all.mjs --matrix-only                           # rebuild matrix.md from the checked-in results
node fixture/serve.mjs                                   # just the fixture site, to look at it

Needs Node 20+ and, for the two .NET clients, the .NET 10 SDK; run-all.mjs builds those two projects
itself. There is exactly one browser: the Chrome for Testing that npm install downloaded. Playwright
connects over CDP to that same binary rather than to a browser of its own, so no playwright install is
needed and no client's numbers are a different Chrome's numbers.

raw/ holds the per-run JSON-lines logs and the scenario metadata. It is gitignored; only the aggregated
results are checked in.

The proxy Copy Chapter

proxy.mjs starts an HTTP server on an ephemeral loopback port and does two things.

It serves the discovery documents, /json/version, /json/list, /json and /json/protocol, by
fetching Chrome's and rewriting every ws://host:port — and every ws=host:port inside a
devtoolsFrontendUrl — to point at itself. Without that rewrite a client that connects by URL
(connect({ browserURL }), connectOverCDP(url)) reads the endpoint out of /json/version and connects
straight to Chrome, and the recording is empty.

It relays WebSockets, accepting a connection on any path and opening a matching one to Chrome on the
same path, so both the browser endpoint (/devtools/browser/) and any page endpoint work. Frames are
relayed byte for byte: the proxy never rewrites a frame, never answers a method itself, and never reorders
anything.

Every frame becomes one JSON line:

{"seq": 41, "t": 1832, "direction": "c2b", "sessionId": "…", "id": 12,
 "method": "Runtime.callFunctionOn", "paramsKeys": ["functionDeclaration", "objectId", "arguments"],
 "paramsValues": {"awaitPromise": true, "returnByValue": false}}

• Requests record parameter keys. Values are recorded only where the value is itself the finding:
  the session model (Target.setAutoAttach's flatten, waitForDebuggerOnStart, autoAttach, filter),
  the shape of a result (Runtime.evaluate / callFunctionOn's awaitPromise, returnByValue,
  generatePreview, userGesture), and the names a client expects an implementation to accept
  (Page.createIsolatedWorld's worldName, Runtime.addBinding's name). No script source, no page
  content, no cookie values, no URLs.
• Responses are correlated to requests by (sessionId, id), so each request row carries the
  resultKeys it got back, or the {code, message} it failed with. The pair is the key, not the id alone:
  a browser-level id and a session-level id collide otherwise.
• A frame carried inside Target.sendMessageToTarget / Target.receivedMessageFromTarget is unwrapped
  and recorded too, so the pre-flattened session model would show up as protocol traffic rather than as
  one opaque command. No client recorded here uses it — every one of them asks for flattened sessions —
  but a client that did would not go unrecorded.

Scenario scripts mark step boundaries with GET /__mark?name=<step> on the same server, which puts the
mark in the same log as the frames; slicing per step is then a matter of reading the log in order, with no
clock comparison. Each mark waits 250 ms first, so the events a step caused are attributed to that step
rather than to the one after it.

The scenario Copy Chapter

fixture/index.html is deliberately ordinary: a heading, three links (one #hash, one to a second page,
one external-looking one that is never followed), a form with a text input, a checkbox, a <select> and a
<textarea>, a button that sets document.title and appends #late after 300 ms, an interval that
mutates a ``, a cookie, a localStorage write, a console.log and a console.error, and a
fetch('/api.json') on load. page2.html is a plain second document so that goBack crosses a real
navigation.

Every client walks the same twenty-five steps in the same order (steps.mjs is the list). A client that
cannot do a step records it as skipped rather than substituting something else — the per-step columns of
the matrix only mean something if they compare like with like.

Which steps are not what their names suggest Copy Section

This is the single most important caveat in the output, and it is what makes the matrix readable:

• $, $$, waitForSelector, type, select, content, title, evaluate and the localStorage
  read are all Runtime.callFunctionOn. Both client families ship a JavaScript "injected script" into an
  isolated world and call into it; the query, the wait loop and the text extraction happen in the page,
  not in the protocol. DOM.* never appears for any of them. So a DOM domain that only implements
  getDocument/querySelector satisfies nobody, and a Runtime.callFunctionOn that handles object
  handles, returnByValue both ways and awaitPromise satisfies almost everybody.
• DOM appears only to turn a JavaScript handle into something clickable. DOM.describeNode +
  DOM.resolveNode for Puppeteer; DOM.scrollIntoViewIfNeeded + DOM.getContentQuads for Playwright.
  Neither client ever sends DOM.enable or DOM.getDocument.
• click and type are Input.dispatchMouseEvent / Input.dispatchKeyEvent at coordinates, resolved
  by the step above. That is why the campaign's flat-box renderer has to answer a box for every element.
• cookies is Storage.getCookies / Storage.setCookies, not Network.getCookies, for all four
  clients.
• goBack is Page.getNavigationHistory + Page.navigateToHistoryEntry. It is also the step where a
  waiter has to be careful: Chrome restores the previous page from the back/forward cache, which fires no
  load event, so Playwright's default waitUntil: 'load' times out and the scenario asks for 'commit'.
• pdf is Page.printToPDF returning a stream handle, then IO.read until done and IO.close.
  Both client families take the stream, not the inline base64.
• screenshot is Page.captureScreenshot for Puppeteer, and additionally Page.getLayoutMetrics plus
  two evaluations for Playwright.
• Request interception is Fetch, not Network. Fetch.enable with URL patterns, Fetch.requestPaused,
  Fetch.continueRequest — plus Network.setCacheDisabled on the way in.
• newContext is Target.createBrowserContext, and every page lives in a flattened session. No client
  recorded here ever sends Target.attachToTarget; all four use Target.setAutoAttach with
  flatten: true and let the browser attach for them.

The best-effort capture Copy Chapter

devtools-frontend.json is marked bestEffort and is not the canonical scenario. The Chrome DevTools
frontend is a user interface, not a client library: it has no goto/click/evaluate API to drive. It is
also pointed at a Node inspector target rather than a page, because a Node-flavoured target is what
Jint.DevTools will look like. What is recorded is its passive handshake plus whatever the Sources panel
asks for, obtained by loading the frontend with &panel=sources; no UI was driven and no breakpoint was
set, because driving DevTools' own shadow roots would be a brittle test of its markup rather than of the
protocol.

Two things make it work at all, and both are worth knowing before re-running it:

• Chrome refuses to navigate an ordinary page to devtools://, so the frontend is loaded from
  chrome-devtools-frontend.appspot.com. That host serves by devtools-frontend commit and only serves
  revisions that were rolled into a Chromium release, so the revision is read from the DEPS file of the
  exact Chrome being driven (devtools_frontend_revision at that version tag) rather than from the tip
  of the frontend repository, which the host does not serve. CDP_FRONTEND_REVISION or
  CDP_FRONTEND_URL override the lookup.
• Chrome 148 blocks a request from a public origin to a loopback one
  (net::ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECKS), and the frontend's socket to the proxy is exactly
  that request, so the throwaway browser that hosts the frontend page runs with Local Network Access
  disabled. Without it the recording is silently empty and reads as "the frontend sends nothing".

If no frontend build answers, the file says so in a notRecorded field instead of holding a fake
recording.

The .NET harnesses Copy Chapter

dotnet/Histogram.PuppeteerSharp and dotnet/Histogram.Playwright are two console projects that walk the
same scenario from .NET. They are deliberately outside Jint.slnx — they need a browser and a network,
which is not what the solution builds — and the dotnet/ folder carries its own empty
Directory.Build.props/.targets and a Directory.Packages.props that turns central package management
off, so the MSBuild walk stops before it reaches Jint's own build and neither project can be broken by a
change to it. The client package version lives in one MSBuild property per project, is used by the
PackageReference and is stamped into the assembly, because both packages ship an assembly whose version
reads 1.0.0 and "which client version sent this" is the whole point.

Playwright for .NET needs no browser install: Playwright.CreateAsync() starts the Node driver bundled in
the package, and ConnectOverCDPAsync then attaches to the Chrome the proxy fronts. If that driver cannot
start, the harness writes the reason into its metadata and exits rather than reporting an empty client.

Reading the results, and their shelf life Copy Chapter

tools/devtools-protocol/handshakes/<client>.json holds, per client: the client and Chrome versions, the
scenario sliced into steps with per-method counts, parameter keys, result keys and errors, allMethods and
allEvents in order of first appearance, and the sessionModel.
tools/devtools-protocol/handshakes/matrix.md is generated from those files and holds the cross-client
table, the minimum must-answer set, what the element path adds on top, the commands Chrome answered with an
error, and the per-step breakdown.

• Counts are indicative; the method sets are the answer. A count moves with timing — how many
  Page.lifecycleEvents a load produces, whether a flaky Inspector.targetCrashed shows up — and a diff
  in the counts alone is not a finding. A method appearing or disappearing is.
• A client version bump changes the files, sometimes visibly: Puppeteer's isolated world is named
  __puppeteer_utility_world__, so the recorded worldName carries the version number.
• Step attribution is best-effort at the edges. The 250 ms settle before each mark catches most trailing
  events, but an event that arrives later lands in the next step. Responses do not have this problem: they
  are correlated back to the request's row by (sessionId, id) no matter when they arrive.
• The proxy is not a security boundary. It is a loopback recorder for a browser this tool launched, with
  no authentication, and it exists for the duration of one scenario.

Overview (`tools/cldr-dates/README.md`) Copy Section

CLDR date and time patterns

Jint.CldrDates.Generator writes Jint/Native/Intl/Data/DateTimePatterns.bin,
an embedded resource with CLDR's Gregorian date and time patterns and names for every locale cldr-json carries, and
DateTimePatternData.Data.cs, the header that says where
it came from. DateTimePatternData reads it. It writes the other
calendars' patterns and names beside them, into
DateTimeCalendarPatterns.bin and its header
DateTimeCalendarPatternData.Data.cs, which
DateTimeCalendarPatternData reads
(the other calendars). It is the
[[LocaleData]] issue #4158 moves Intl.DateTimeFormat onto:
a component bag is resolved against it by the format matcher,
DateTimePatternGenerator, which resolves a dateStyle and
timeStyle too, and the ranges of both are written with their interval patterns by
DateTimeIntervalFormat; their reference models and golden tables
are under reference/.

The build never runs the generator. Its outputs are committed, and regenerating them is a manual step taken
when the pinned release changes.

Inputs Copy Chapter

pin.json pins CLDR 48.2 (release-48-2):

Each file is downloaded into a cache directory (by default jint-cldr-dates under the temporary directory; --cache
changes it) and checked against its pin before anything reads it. A cached copy that does not match is fetched again,
and a download that does not match fails the run: do not update the pin to whatever came back without finding out why
it changed.

What is extracted Copy Chapter

For each locale, from the gregorian calendar:

• dateTimeFormats/availableFormats, less the skeletons with a quarter (Q) or week (w, W) field, which ECMA-402
  has no option for, and CLDR's -count- and -alt- variants. That leaves 49 to 61 per locale.
• dateTimeFormats full/long/medium/short, and dateTimeFormats-atTime/standard, which ICU 72 and later join a
  date and a time with ("at", "um", "à").
• dateFormats and timeFormats, the four style patterns each.
• dateTimeFormats/appendItems, and the wide display name of each field they name (dateFields.json's
  fields/<field>/displayName), which is what ICU puts in their {2}.
• months and days, format and stand-alone, every width; eras (eraAbbr, eraNames, eraNarrow); and the
  format am/pm day periods in three widths.
• The flexible day periods a B field writes, format context, in the same three widths: noon and morning1 to
  night2, empty where CLDR has no name, and a missing wide or narrow one filled with the abbreviated one, as ICU's
  DateFormatSymbols fills it. ICU writes only the format context and has not written midnight since ICU 57, so the
  stand-alone names and midnight are left out.
• The day period rules that pick a flexible day period for an hour, from cldr-core's supplemental/dayPeriods.json,
  looked up for each locale as ICU's DayPeriodRules::getInstance looks them up: the locale, then each truncation of
  it, not the CLDR parent chain, so zh-Hant (whose parent is the root) has zh's. A locale whose language has none
  gets the root's, am and pm, which ICU writes the same as no rules. Each is written as one character per hour —
  the period's position in the names (1 morning1 to 8 night2), or a/p — then n where the rules have
  noon at 12:00; English's is 111111111111222222333444n. A rule set fails the run unless every hour of the day is
  in exactly one period, every period is whole hours, and only midnight at 00:00 and noon at 12:00 are at rules.
• dateTimeFormats/intervalFormats: intervalFormatFallback, and each skeleton's pattern for each greatest-difference
  letter ICU reads (G y M d a B h H m; CLDR's -alt- variants are left out). They are stored as ICU's
  DateIntervalInfo ends up holding them, one pattern per skeleton and field (a and B are one field, and so are h
  and H): each from the nearest locale of the parent chain that has it — a locale's own being the letters whose
  pattern differs from its parent's — and within one locale the first letter in binary order, so zh-Hant's B
  pattern for h is read and its a one is not.

The other calendars are extracted into a resource of their own (the other calendars).

The run fails, listing every problem at once, unless: cldr-dates-full and availableLocales.json name the same
locales; every value is present and non-empty (a flexible day period may be missing), with twelve months, seven weekdays, two eras and am/pm; every pattern
parses (every quote closed) and uses only the letters ECMA-402's fields map to, GyMLdEcabBhHKkmsSzvO; every join
and appendItems pattern places {0} and {1} (and appendItems only {2} besides) with no letter outside quotes; the
XML's and cldr-core's parent tables agree; every locale's parent chain reaches the root through locales cldr-json
carries; and every interval pattern splits into its two dates where a field letter recurs (ICU's
splitPatternInto2Part), and every fallback places both. Then it decodes what it wrote, independently of the writer, and requires every locale to come back exactly.

CLDR 48.2 itself breaks the letter rule six times — de-CH GyMEd and gd yMMM, ksh yM and sc yM use the
week-numbering year Y, and fa and fa-AF have an HHmmZ skeleton — and writes one numbering-system override,
haw's short date (M=romanlow). They are kept as CLDR writes them (the override is dropped: the resource has
nowhere to put it) and are listed by name in CldrLocale.cs, so a new one fails the run, and so does a listed one
that no longer occurs. Jint.Tests pins the same list. So is fa's (and fa-AF's) GyMMM month pattern,
LLL تا MMM y G, which repeats no letter (KnownUnsplittableIntervals).

The other calendars Copy Chapter

DateTimeCalendarPatterns.bin carries ten calendars, for every locale: buddhist, japanese, roc, hebrew,
persian, indian, coptic, ethiopic, ethiopic-amete-alem (ethioaa) and islamic, which serves all five Islamic
identifiers (the generator requires ca-islamic-civil.json, -rgsa, -tbla and -umalqura to be ca-islamic.json
in every locale, and their XML to define nothing). chinese and dangi are not carried: they write a related year and
a year name, in a lane of their own. For each locale and calendar it holds the calendar's availableFormats,
dateFormats, timeFormats, atTime joining patterns, appendItems, intervalFormats and fallback, its month names
(none for the three calendars that write the Gregorian months; thirteen for the Coptic and Ethiopic ones; thirteen and
Adar II for the Hebrew one) and its eras (the Japanese calendar keeps Meiji to Reiwa, CLDR's 232 to 236). Weekdays, day
periods, field names and the dateTimeFormats a range joins its date and time with are the Gregorian locale's, as in ICU.

cldr-json resolves every element through CLDR's inheritance, which is what ICU reads for most of this. Three things ICU
decides by which locale defines a value (icu4c dtptngen.cpp, smpdtfmt.cpp), and the generator reads those from
cldr-common's XML (CldrXml.cs), counting an element as ICU's data build does:
a pattern of its own, not an alias, not the inheritance marker ↑↑↑, not draft="unconfirmed" or "provisional".
So read, CLDR 48.2's XML says which locales have each calendar's DateTimePatterns and DateTimePatterns%atTime
exactly as ICU 78.3's data does, 2,724 of 2,724.

• Style patterns. ICU keeps a calendar's date, time and joining patterns in one array, calendar/<name>/DateTimePatterns,
  which the root aliases to the generic calendar's. A locale has it only where it defines one of them, so a calendar's
  time styles are those of the nearest locale defining its (or the generic calendar's) date patterns: en-GB's Buddhist
  h:mm a is en-001's. The date and time formats are written from that locale.
• Joining patterns. A date and a time are joined with the calendar's %atTime, which the root aliases to nothing;
  failing that with the Gregorian %atTime of the nearest locale defining one (zh-Hant's {1}\u2009{0}, identical to
  its standard pattern); failing both, with the calendar's own joining patterns (lv's {1}, {0}).
• availableFormats order. ICU adds a calendar's own entries from every locale of the chain before the generic
  calendar's it inherits; each record lists the skeletons its locale defines for the calendar itself, and the format
  matcher adds those first. The order decides ties (en-GB's Hebrew Sat, 30 Kislev).

The validation lists are their own: CalendarExtraction.KnownNumberingOverrides (haw's Roman months, ja's 元年,
he and yi's Hebrew numerals, all dropped as the Gregorian haw override is), KnownLetterExceptions (the generic
calendar's week-numbering Y in six locales, fa's Z and ko's e) and KnownUnsplittableIntervals (fa's), each
keyed by locale, calendar (none for every calendar) and path, each failing the run when it no longer occurs.

Regenerating Copy Chapter

From the repository root:

dotnet run --project tools/cldr-dates/Jint.CldrDates.Generator -c Release

It prints each resource's size, in total and for the largest blocks, and leaves a resource whose content is the
committed one as it is. --check regenerates in memory and compares the content with the committed headers instead of
writing anything.

The deflated bytes depend on the runtime's zlib, so a different .NET can write a different .bin from the same
inputs. The header therefore records two hashes: the file's, and the payload's — the inflated index followed by
every inflated block, which does not depend on the encoder. --check compares the payload, and
IntlDateTimePatternDataTests recomputes it from the embedded resource, so a .bin and a header from different runs
fail the test.

The resource Copy Chapter

All integers are unsigned LEB128 varints; a string is a varint byte length followed by UTF-8.

file:   "JDTP"  version=2  varint indexLength  varint indexDeflatedLength  index (raw deflate)  blocks
index:  string cldrVersion
        varint slotCount, slotCount x string slotName
        varint blockCount, blockCount x { string language, varint offset, varint deflatedLength, varint length,
                                          varint localeCount, localeCount x string locale }
        varint parentCount, parentCount x { string locale, string parent }
block:  one record per locale, in the index's order (raw deflate; offset counted from the end of the index)
record: varint n, n x { varint gap, string value }        slots: the index is the previous one + gap + 1
        varint n, n x { string skeleton, string pattern } availableFormats entries new or different, in ordinal order
        varint n, n x string skeleton                     availableFormats entries the parent has and this locale drops
        varint n, n x { string skeleton, byte field, string pattern }
                                                          interval patterns new or different, in ordinal order
        varint n, n x { string skeleton, byte field }     interval patterns the parent has and this locale drops

An interval pattern's field is one of G y M d a h m, the letter ICU's interval index names it by. Version 1 had no
interval lists.

A slot is one fixed-position value; the 207 of them are listed in
SlotLayout.cs, each named by its JSON path (the day period rules by
supplemental/dayPeriodRuleSet), and the index carries the
names so the loader can check them against its own offsets. Every locale but the root (und) stores only what
differs from its CLDR parent (TR35): the parent table's
entry, else the root for a language-and-script locale whose script is not the language's likely one, else the
locale with its last subtag removed (a language's parent is the root). cldr-json leaves out the default-content
locales, so a parent it does not carry is skipped for that parent's own (ca-ES-valencia inherits from ca, past
ca-ES). The index lists every parent that is not plain truncation; the loader truncates for the rest.

There is one deflated block per language (the locale's first subtag), so a process inflates only the languages it
uses — plus the root's, which every language's records are relative to, and a parent's in another language where
CLDR has one (nb and nn inherit from no, hi-Latn from en-IN, ht from fr-HT).

DateTimeCalendarPatterns.bin follows DateTimePatterns.bin's language blocks, locales and parents without repeating
them:

file:   "JDTC"  version=1  varint indexLength  varint indexDeflatedLength  index (raw deflate)  blocks
index:  string cldrVersion
        varint calendarCount, calendarCount x { string cldrName, varint n, n x string identifier, varint monthCount,
                                                varint n, n x string eraKey, varint slotCount, slotCount x string slotName }
        varint blockCount, blockCount x { string language, varint offset, varint deflatedLength, varint length,
                                          varint localeCount }
block:  each locale of the language in DateTimePatterns.bin's order, and for each, each calendar in the index's order:
record: a DateTimePatterns.bin record over the calendar's own slots, relative to the parent's record of the calendar,
        then varint n, n x string skeleton                the availableFormats the locale defines for the calendar

A calendar's slots are its date, time and atTime formats, appendItems and interval fallback (24), its months by context
and width, and its eras by width; the index names them. Holding a locale's records of every calendar side by side is
what lets deflate find what the calendars share, which are all the generic calendar's patterns under other eras and
months: 175 KB deflated for the ten, where one block per calendar and language costs 860 KB. A process inflates a block
the first time a calendar is asked for in its language, and reads only that calendar's records out of it.

The format matcher's reference model Copy Chapter

reference/format_matcher.py is a Python model of ICU's DateTimePatternGenerator as
V8 drives it, over the same cldr-json inputs, and DateTimePatternGenerator is its C# port. Neither the build nor the
tests run it; it writes reference/golden.tsv, which Jint.Tests
(IntlDateTimeFormatMatcherTests) embeds straight from here and checks the port against: 51 locales by 25 option bags,
each formatted at two instants, with the pattern the model chose and the options resolvedOptions() reports.

The table is the model's output over CLDR 48.2, not an engine's, so a difference between the CLDR an ICU build carries
and the one Jint embeds cannot hide in it. Its last column is what ICU writes where it differs, taken from
reference/probe-golden.js run under Node: with Node 24.19 (ICU 78.3, CLDR 48.0) every
row's text agrees, and 21 rows' resolvedOptions() differ, deliberately — 20 where V8 reads a letter inside a quoted
literal as a field (Spanish MMMM 'de' y "has" a day), and Japanese hour12: true, which test262 puts on h11 and V8
on h12. IntlDateTimeFormatMatcherTests.KnownIcuDifferences lists them.

To regenerate, with cldr-json unpacked as the model's docstring describes:

node reference/probe-golden.js > icu-golden.tsv
python reference/format_matcher.py compare <cldr-json-root> icu-golden.tsv
python reference/format_matcher.py golden <cldr-json-root> icu-golden.tsv > reference/golden.tsv

compare prints every row where the model and ICU disagree. Run with the design's wider set — every cldr-json
locale ICU resolves to itself, 641 of them, in the comma-separated PROBE_LOCALES both scripts read — the model agreed
with Node on 16,023 of 16,025 formatted strings. The two that differ are data rather than matching: CLDR 48.2 joins an
fr-ML date and time with {1}, {0} where Node's CLDR 48.0 writes {1} {0} (its dateStyle + timeStyle output
shows the same), and tok (Toki Pona) writes a date and time from data that differs between the two releases. A change
to the matcher goes into the model first, then into the port, and the table is regenerated in the same pull request.

The interval format's reference model Copy Chapter

reference/interval_format.py is a model of ICU's DateIntervalFormat as V8 drives it,
on top of format_matcher.py, and DateTimeIntervalFormat is its C# port: V8 creates the interval format for the
skeleton of the pattern a single date is written with — the one the matcher chose, or a dateStyle/timeStyle's —
with the resolved hour cycle; the skeleton is split into a date and a time
and normalized, the nearest interval skeleton is found and its pattern widened to the request, a date skeleton is
extended by the field that differs (MMMd to yMMMd), a date and a time on one day are the date once joined to the
time's interval by the medium dateTimeFormats, and any other range is the two whole dates in the fallback. It writes
reference/range-golden.tsv, which IntlDateTimeFormatRangeTests embeds: the 51 locales,
23 bags — 15 component bags, the four date styles, the short and medium time styles and two pairs of them — and up
to six pairs of dates, each differing first in the field it is named after, with the text and every part's type, source
and length. A range keeps the U+2009 THIN SPACE CLDR writes around its dash, as V8 does; U+202F is U+0020, as in every
lane (V8 keeps it in a range).

node reference/probe-range-golden.js > icu-range-golden.tsv
python reference/interval_format.py compare <cldr-json-root> icu-range-golden.tsv
python reference/interval_format.py golden <cldr-json-root> icu-range-golden.tsv > reference/range-golden.tsv
python reference/interval_format.py ties <cldr-json-root>

With Node 24.19 every one of the table's 5,610 rows has the same text, and 5,600 the same parts. The other ten are
V8 reporting as shared a part ICU writes from the end date, which the specification does not allow a shared part:
fa writes the month stand-alone before the dash and in the format context after it, two fields to ICU, and sw
writes the month of a month range once, after the second day; the model and Jint report those parts as the end date's.
Over the 641 locales the model agrees with Node on 70,443 of 70,510 rows; the others are those two shapes (fa,
fa-AF, sw and its regions, wae), fr-ML and tok's data as above, haw's short date, whose M=romanlow override
the resource drops, and yo's (and yo-BJ's) yMMMEd year pattern,
which repeats the year inside its first date, so that ICU splits it there and writes part of the start from the end
date where Jint writes each part from the date its source names. ties reports every interval skeleton lookup with
two candidates at the least distance, where ICU's hash-table order would decide: there is none, so walking the
skeletons in ordinal order is exact.

The other calendars' table Copy Section

format_matcher.py reads a calendar's data from its ca-<calendar>.json and, for the three things ICU decides by which
locale defines a value, from cldr-common's XML, as the generator does (the other calendars); it
expects the calendar packages unpacked under <cldr-json-root>/cal//package and cldr-common-48.2.zip beside
them. It writes reference/golden-calendars.tsv, which IntlDateTimeFormatCalendarTests
embeds: 11 locales chosen to exercise ICU's rules, every calendar but islamic-tbla (whose data is islamic-civil's), and
21 component bags and styles, at the two instants, each instant dated in the calendar as ICU dates it
(CALENDAR_DATES).

python reference/format_matcher.py calendar-cases > calendar-cases.tsv
node reference/probe-calendars.js calendar-cases.tsv > icu-calendars.tsv
python reference/format_matcher.py compare-calendars <cldr-json-root> icu-calendars.tsv
python reference/format_matcher.py golden-calendars <cldr-json-root> icu-calendars.tsv > reference/golden-calendars.tsv

With Node 24.19, 2,535 of the table's 2,541 rows have the same text; the six others are he's Hebrew date styles,
which ICU writes in Hebrew numerals (numbers="hebr") and Jint in the formatter's digits. 574 rows' resolvedOptions()
differ, in two ways V8 reads a format record that the specification does not: it recognizes an era only in a run of three
or more G, so the M/d/y G every one of these calendars writes reports no era, and it reads a letter inside a quoted
literal as a field. calendar-cases and compare-calendars take a file of locales as an extra argument, and then run
every calendar and all 31 cases: over the 641 cldr-json locales ICU resolves to themselves the model agreed with Node on
238,395 of 238,452 rows' text. The 57 others are he and yi's Hebrew numerals, haw's Roman months, the
week-numbering Y that gl, ksh, my and te patterns use (ICU writes it as the Gregorian week year in these
calendars), and fr-ML's joining pattern, which differs between CLDR 48.0 and 48.2.

`dateStyle` and `timeStyle` Copy Section

The model also writes the style table, reference/golden-styles.tsv, which
IntlDateTimeFormatStyleTests embeds the same way: the 51 locales by 53 cases — each date and time style alone and in
all sixteen pairs, twelve with an hourCycle or hour12 the locale does not write, and seventeen Temporal values —
with the pattern, the text at the two instants, the UTC zone name the text writes, and what resolvedOptions()
reports. A style is modelled as V8 drives ICU: the locale's dateFormats/timeFormats, a date and a time joined by
the atTime connector of the date's width, and where the resolved hour cycle is not the pattern's, its skeleton
without the day period and with the cycle's hour letter matched again. A Temporal value without all of a style's
fields gets Temporal's AdjustDateTimeStyleFormat: the matcher over the fields it has. For the text only, the model
reads one more cldr-json file than the generator, timeZoneNames.json (the Etc/UTC name), and writes the flexible
day period zh-Hant's time patterns use from supplemental/dayPeriods.json as the generator reads it.

Node's V8 does not ship Temporal, so the case list the probe reads is the model's own, and a Temporal case is asked of
ICU as the component bag AdjustDateTimeStyleFormat matched:

python reference/format_matcher.py style-cases <cldr-json-root> > style-cases.tsv
node reference/probe-styles.js style-cases.tsv > icu-styles.tsv
python reference/format_matcher.py compare-styles <cldr-json-root> icu-styles.tsv
python reference/format_matcher.py golden-styles <cldr-json-root> icu-styles.tsv > reference/golden-styles.tsv

With Node 24.19 every row's text agrees, and 22 rows' resolvedOptions() differ for the reasons above: 20 quoted
literals V8 reads as fields, in the component bags the Temporal cases match to, and Japanese hour12: true. Jint's
text differs from the table only in the long zone name, which it writes in English in every locale; the test counts
those rows. style-cases and compare-styles take a file of locales as an extra argument: over the 641 cldr-json
locales ICU resolves to themselves the model agreed with Node on 33,951 of 33,973 rows, and the 22 that differ are data
— fr-ML's connector as above, haw's short date, whose M=romanlow override the resource drops (ICU writes xii),
sr-Cyrl-ME's long UTC name (ICU's is in Latin script), and tok.

Moving to a later CLDR release Copy Chapter

1. Update pin.json: the versions and tag, each tarball's URL and npm dist.integrity (from
   https://registry.npmjs.org//<version>), the XML's URL and SHA-256, and cldr-common's.
2. Run the generator. A validation failure is upstream data to read, not a list to widen: decide for each new entry
   whether it belongs in KnownLetterExceptions or KnownNumberingOverrides, with a comment saying what it is.
3. Update the expectations in Jint.Tests/Runtime/IntlDateTimePatternDataTests.cs: CLDR's values for a handful of
   locales, the locale count and the list of known letter exceptions.
4. Regenerate reference/golden.tsv,
   reference/golden-styles.tsv,
   reference/range-golden.tsv and
   reference/golden-calendars.tsv from the new release.
5. Run Jint.Tests.

Update from a release, never entry by entry: the data is CLDR's own, under the Unicode License v3
(CREDITS.txt).

Overview (`tools/devtools-frontend-smoke/README.md`) Copy Section

DevTools front-end smoke test

Everything else in this repository that claims Chrome DevTools works against Jint claims it from the
protocol side: a test sends a command and asserts the answer. That proves the server answers. It does not
prove that a person who opens DevTools sees anything.

This drives the other half. It launches Jint.Repl --inspect, loads the real Chrome DevTools front
end — unmodified, at the revision that shipped in the Chrome being driven — points it at that Jint
process, and then reads the panels: the Sources navigator, the editor, the Console, the Scope pane, the
call stack. Every assertion is made against what the front end rendered, through its own shadow roots.

It is Jint.DevTools/docs/manual-checklist.md minus the
manual part. Run this when the protocol surface changes; walk the checklist by hand for the steps the table
below says are not driven.

Running it Copy Chapter

cd tools/devtools-frontend-smoke
npm install                 # also downloads Chrome for Testing (puppeteer's postinstall)
node smoke.mjs

Puppeteer is pinned to the same version tools/cdp-histogram pins, so both tools use
one Chrome for Testing download and neither one's evidence is a different browser's.

The Jint side has to be built first — this tool never builds anything, because a second MSBuild in a working
tree somebody else is building is its own kind of flake:

dotnet build -c Release Jint.Repl/Jint.Repl.csproj

It looks for artifacts/bin/Jint.Repl/release/Jint.Repl.exe, then the extensionless apphost, then
Jint.Repl.dll (run through dotnet), and says all three plus the build command when it finds none.

The recording proxy is tools/cdp-histogram/proxy.mjs, imported rather than copied. Node resolves that
file's import 'ws' from its directory, not from this one, so it needs a copy of ws next door:

node -e "await (await import('node:fs/promises')).cp('node_modules/ws', '../cdp-histogram/node_modules/ws', { recursive: true })"

Both paths are gitignored, so this changes nothing that is checked in, and smoke.mjs prints exactly that
command if the import fails. A full npm install in tools/cdp-histogram works too and does more.

One thing is not imported: the devtools-frontend revision lookup. It lives in
tools/cdp-histogram/scenarios/devtools-frontend.mjs, which is a script that runs a whole capture on import
and exports nothing, so frontend.mjs re-derives it — same DEPS file, same rule, same two overrides.

What it drives Copy Chapter

fixture/app.js is what the engine runs, and it is short on purpose. It logs a string and an object, so the
Console has an object preview to render; it declares named functions, so the editor and the gutter have
something worth looking at; a setTimeout inside a one-second setInterval throws, so an uncaught exception
is reachable; and the function the breakpoint lands in holds a function-valued local, so the Scope pane has a
script function of its own to render rather than only the native ones on Object.prototype.

The heartbeat re-arms rather than firing once, and that is deliberate. The script itself finishes in
milliseconds while the front end needs seconds to download and connect, so a single setTimeout would have
thrown before anybody was listening. The same heartbeat is what makes a breakpoint hittable at all:
computeTotal is called once a second forever, so the front end can set a breakpoint whenever it likes and
be paused within a second of doing it.

The steps, and what each one proves Copy Chapter

Each step gets a 60-second budget, a screenshot, a DOM dump, and a row in out/summary.json carrying what it
observed. A step that could not be driven is recorded as not-driven with what was seen instead — never as a
pass, and never as a weaker assertion wearing the strong one's name.

How it reads a user interface Copy Chapter

DevTools is built out of custom elements, and nothing interesting is reachable from
document.querySelector. frontend.mjs installs one helper, window.__smoke, before the page loads; it
walks every open shadow root and answers four questions — which elements match a selector, what they say,
their whole text, and where one is on screen. Everything else goes through it, and clicks are real mouse
events at the coordinates it returns rather than synthetic el.click() calls, because the gutter and the
tree both listen for the real thing.

The UI table at the top of smoke.mjs is every selector the tool bets on. When DevTools' markup moves,
that table is the list to read.

Three things make loading the front end possible at all, and all three are inherited from
tools/cdp-histogram:

• Chrome refuses to navigate an ordinary page to devtools://, so the front end comes from
  chrome-devtools-frontend.appspot.com.
• That host serves by devtools-frontend commit and only serves commits that were rolled into a Chromium
  release, so the revision is read from the DEPS file of the exact Chrome being driven rather than from the
  tip of the front-end repository.
• Chrome blocks a request from a public origin to a loopback one, and the front end's socket to Jint is
  exactly that request, so the browser runs with Local Network Access checks disabled. Without it the page
  loads, connects to nothing, and every assertion fails for a reason that has nothing to do with Jint.

What a run leaves behind Copy Chapter

out/ is gitignored; a run is evidence for a human, not an artefact to check in.

• out/NN-<step>.png — a screenshot after every step, pass or fail.
• out/dom/NN-<step>.txt — a compact outline of the whole rendered tree, shadow roots included. This is what
  to read when a selector stops matching.
• out/summary.json — the environment (Chrome version, front-end revision, the front end's own console
  errors, Jint's stdout), every step's verdict and what it observed, and the protocol traffic sliced per step.
• out/protocol.jsonl — every frame between the front end and Jint, one JSON line each, written by
  tools/cdp-histogram/proxy.mjs. Step boundaries are in the same log, because each step marks itself on the
  proxy's /__mark endpoint before it runs.

Honesty: what these passes are not Copy Chapter

Every step in the checked-in run drove the real user interface and none was faked. What follows is the list
of places where a pass means something narrower than its name, and the things that were not attempted.

• The navigator's tree is walked by expanding whatever folder it currently shows, one round at a time,
  rather than by knowing the shape in advance: a file:// domain has the folders of the path under it, and
  how many there are depends on where the checkout is.
• The Console's message list is virtualized. Only the visible tail is in the DOM, and the heartbeat
  pushes everything else off it, so the message logged before the front end connected cannot be read
  directly. Step 4 types it into the Console's Filter box first. That is still driving the UI, and it has a
  bonus: a filtered-in message that arrived before the socket existed is proof that the console journal Jint
  replays on Runtime.enable reached the front end.
• The editor is virtualized too, though not at this file's size. deepTexts truncates each entry at 400
  characters for readability; the editor is read with deepFullText, which does not. A step that asserts on
  a long text and uses the wrong one silently reads a prefix — that is how the first run of step 3 failed.
• Step 9 asserts that no function renders as ƒ undefined() and that one script function renders with its
  own name and parameter; it does not assert that everything else in the pane is right. What the pane was
  showing at the moment of the assertion is recorded in summary.json under functionValuedBindings either
  way. The fixture's describe local exists for this step: everything else visible at that pause is native,
  and a native function would only prove the [native code] half.
• --inspect-brk, stepping (over / into / out), watch expressions, conditional breakpoints, Debugger.pause,
  the Profiler and coverage, and the Memory and Performance panels are not driven at all. Nothing here says
  anything about them.
• The screenshots are of a headless Chrome. SMOKE_HEADED=1 renders it in a window instead.
• The protocol recording names methods, result keys and errors — not argument values. That is
  proxy.mjs's deliberate design, and it is enough to show that a command was sent, answered or refused. It
  is not enough to see what a command carried, so the defect notes below that turn on a value were
  confirmed with a direct protocol client rather than by this tool.
• Reading a user interface by class name is a bet on somebody else's markup. This is why the tool is not
  in CI: a DevTools release can break it without Jint changing, and a failure here is a prompt to look, not a
  regression by itself.

What this run found in Jint's DevTools server, and what became of it Copy Chapter

The first run of this tool found four defects that no protocol test had caught, plus one inconsistency that
needed a decision. All five are fixed, and each is now asserted by the step named beside it rather than only
described here.

• A frame the engine was entered at had no name and no functionLocation (step 8). The Call Stack pane
  showed computeTotal over an unnamed row where V8 shows the timer callback's own name. Two defects wore
  that one symptom: a host Invoke of an anonymous function produced a frame named with the empty string,
  and a setTimeout / setInterval callback had no frame at all, because the timer queue reached its
  callback through ICallable.Call, which pushes nothing onto the engine's call stack. The pane now reads
  computeTotal / heartbeat / (anonymous), each row linking to its own line.
• RemoteObject.description for a function was a rendered label where the front end expects source text
  (step 9). Jint sent ƒ computeTotal(); the front end treats that field as Function.prototype.toString
  output and parses the name back out of it, so every function in the Scope pane and in
  Runtime.getProperties rendered as ƒ undefined() — eleven of them in the first run's screenshot. It
  now sends the declaration, and a PropertyPreview of a function carries value: "", which is what a real
  Chrome sends and was recorded rather than assumed.
• Runtime.consoleAPICalled carried no stackTrace (step 5), so no console message had a source anchor
  where V8 puts the file and line the call came from. Every message now carries its call site, resolved back
  to a script identifier so the anchor is clickable.
• The front end called Runtime.getExceptionDetails once per uncaught exception and was refused every
  time (-32601, step 6). The command was listed as deliberately absent on the grounds that nothing
  retains an exception's details past the report that carried them — which turned out to be answering the
  wrong question: the front end asks about an error object it is holding, and the details are
  reconstructed from that.
• /json/list reported the target's url as file:///D:/…/app.js while Debugger.scriptParsed reported
  the same file as D:/…/app.js (step 2), which is why the navigator filed the script under "(no domain)"
  with its whole path for a name. The decision taken: the engine's source names stay exactly what the host
  passed — a stack trace prints them, and they are the host's — and the protocol maps a name that is an
  absolute filesystem path to a file:// URL on the way out. Both documents now name one location.

Two refusals still show up in the recording and are working as designed, listed so a reader does not file
them twice: Network.* is -32601 because an engine target has no Network domain, and Runtime.evaluate
with throwOnSideEffect is -32000 "Side-effect free evaluation is not supported", which costs the Console
prompt its eager-evaluation preview and nothing else.

One thing a reader of a screenshot should not file either: the text of a rendered error in the Console
still carries the host's own source names — at reconcile (D:/…/app.js:55:15) — because that text is
Error.prototype.stack, which is the engine's and the host's. The clickable anchor beside it is the mapped
app.js:55.

Overview (`tools/devtools-protocol/README.md`) Copy Section

Vendored Chrome DevTools Protocol

js_protocol.json and browser_protocol.json are copied verbatim from the json/ directory of
ChromeDevTools/devtools-protocol, at commit

ea39a11d80de9a08ce2af03f52125ed2e462cf84

which is npm [email protected], retrieved 2026-09-01. pin.json is that record in
machine-readable form and is what the generator stamps into the code it emits; this file and it must
say the same thing.

devtools-protocol-LICENSE is that commit's LICENSE. The protocol description is
Copyright The Chromium Authors and is redistributed here under the 3-Clause BSD License it carries.
Neither vendored file is edited — a fetch at the pinned commit has to produce no diff, which is
why .gitattributes pins both to LF. The one file here that is not upstream's is jint_protocol.json,
below.

The domain that is ours Copy Chapter

jint_protocol.json sits beside the two vendored files, in the same format, and is not part of the
fetch: it is this repository's own, and a re-fetch at the pinned commit still produces no diff in the two
files above. It describes the Jint domain — getMarkdown, getText, getAccessibilitySnapshot — the way
Lightpanda describes its LP one, and the generator reads all three files alike, so a Jint command gets
data transfer objects, a dispatch base and a manifest entry exactly as a Chrome command does. The one place
they differ is the citation: a member of a domain Chrome does not have is cited against this file rather
than against Chrome's documentation, because ProtocolCitationTests resolves every chromedevtools URL
against the vendored JSON and a Jint anchor would name nothing there.

It declares the same protocol version as the vendored files, which the reader checks. Adding a domain to it
is the same three steps as any other: describe it here, add its commands to manifest.json, regenerate, and
override the virtuals.

A bump is a code change Copy Chapter

Re-pointing the pin is not a configuration edit that lands on its own. Upstream renames methods, moves
them between domains, changes a parameter from optional to required and retires deprecated commands, and
every one of those changes the generated dispatch surface. So a bump is:

1. Fetch the two files at the new commit, update pin.json and the commit above.
2. Regenerate (below) and read the diff of Jint.DevTools/Protocol/Generated/. That diff is the
   upstream change, stated in the vocabulary this repository compiles.
3. Fix whatever the diff broke, in the same pull request.

The same discipline Jint.Tests.Test262/Test262Harness.settings.json's SuiteGitSha carries, and for
the same reason: a pin that moves without anybody reading what moved is an upstream normative change
landing unread.

Regenerating Copy Chapter

dotnet run --project tools/devtools-protocol/Jint.DevTools.ProtocolGenerator -c Release -- \
    --protocol tools/devtools-protocol \
    --manifest tools/devtools-protocol/manifest.json \
    --output Jint.DevTools/Protocol/Generated

The output is checked in, and Jint.Tests.DevTools/Protocol/GeneratedProtocolIsCurrentTests.cs runs
the same emitter in memory and compares it byte for byte with what is on disk. So an edit to
manifest.json without a regeneration fails the build, and a hand edit of a .g.cs file fails it too.

A Roslyn source generator was considered and rejected: the System.Text.Json context has to be generated
over the DTOs and generators do not chain, Jint.SourceGenerators is netstandard2.0 without
System.Text.Json, and a protocol surface is exactly the kind of thing whose diff a reviewer wants to
read.

The manifest Copy Chapter

manifest.json is the boundary between what is described and what is answered.

• generatedDomains — the domains that get DTOs, a <Domain>DomainBase and a <Domain>Events factory
  class. A generated command gets a virtual, and its default answers
  -32601 'Domain.method' wasn't found. An entry is either a domain name or an object:

  jsonc Copy

  "Runtime",                                                  // the whole domain
  { "domain": "Audits", "commands": ["disable", "enable"] },   // these, and nothing else

  The object form generates the commands and events it names and nothing else — including nothing for a
  list it leaves out — and the types it gets are the closure of what those members reach, computed rather
  than listed. A command that is not generated has no virtual and is answered by the dispatch base's
  default case, which is the same -32601 it answered before: the object form changes what is checked
  in, not what a client is told, and ACommandAPartialDomainDoesNotGenerateIsStillMethodNotFound is what
  says so. Which form to use is a judgement about the domain — one whose surface is being filled in stays
  whole, so the next command is an override and a manifest line; one that answers a handful of commands out
  of dozens, and whose remainder describes machinery this engine does not have, names them. Nine domains
  do today, and it took 30% off the generated tree: Audits alone went from 143 KB to 4 KB.

• implementedMethods — the commands Jint.DevTools answers. Each is checked to exist in the vendored
  protocol, and ProtocolManifestTests checks each is overridden on a registered domain and that
  nothing else is.

• implementedEvents — the events Jint.DevTools emits, checked the same way.

• reportedDomains — what Schema.getDomains answers. A domain may only appear here once it has an
  implemented command, so a client feature-detecting through Schema.getDomains is never told about a
  domain that answers nothing.

The generator fails rather than emitting broken code when an entry names something the vendored protocol
does not have, when a $ref crosses into a domain that is not generated and does not resolve to a
primitive alias, and when implementedMethods names a command its own generatedDomains entry does not
generate — which would otherwise be a command the manifest and Schema.getDomains claim and nothing can
override.

What a generated file says about itself Copy Chapter

Every .g.cs carries three lines of provenance:

//     source:   tools/devtools-protocol/browser_protocol.json
//     protocol: version 1.3, ChromeDevTools/devtools-protocol@ea39a11… ([email protected])
//     manifest: tools/devtools-protocol/manifest.json, Audits entries, sha256:5893b4009485

source is the description that file was read from, which is why it is per file: Jint.g.cs comes from
jint_protocol.json, ours, and used to cite the Chrome commit its neighbours come from — provenance naming
the wrong document, which is what a reader has instead of a build when they have only a diff in front of
them. A file generated from our own description names no Chrome commit at all, because a bump cannot move
it.

The manifest digest is over the part of the manifest that shaped the file — that domain's
generatedDomains entry, its implemented commands and its implemented events — rather than over the whole
file. A whole-file digest would rewrite all twenty-four headers whenever any domain gained a command, and
say nothing true about the other twenty-three. ProtocolJsonContext.g.cs and ProtocolManifest.g.cs are
generated from all of it and carry a digest of all of it. Line endings are normalised before hashing, so a
Windows checkout and a Linux one stamp the same digest.

The map type Copy Chapter

The protocol has no map keyword. What it writes instead is a named type declared as "type": "object"
with no properties, and Network.Headers — "request / response headers as keys / values of JSON
object" — is the one every generated domain uses. The emitter reads that shape as a map: no record is
emitted for the type, and every $ref to it resolves to
global::System.Collections.Generic.Dictionary<string, string>. An empty record was what came before, and
it meant a client's headers were not in the request object at all.

Two things about the rule are deliberate:

• Only a named type is a map. An inline "type": "object" member stays a JsonElement, because
  those carry values of mixed shapes rather than strings: Debugger.paused's data holds a remote object,
  an execution context's auxData holds a boolean and two strings, and a dictionary of strings would drop
  the lot silently.
• A repeated header is joined with a newline, which is what Chrome sends, because the Fetch Standard
  keeps every value of a repeated header apart and the protocol's map cannot. That join is the domain's
  business rather than the generator's; see Jint.Browser/DevTools/NetworkDomain.Events.cs.

The handshake recordings Copy Chapter

handshakes/ is what the described protocol looks like from the client side: every CDP method and event
Puppeteer, PuppeteerSharp, Playwright, Playwright for .NET and the Chrome DevTools frontend actually send
and receive while driving one Chrome build through one canonical scenario, one file per client plus
matrix.md. manifest.json decides what is answered; the matrix says what has to be. It is recorded, not
written, by tools/cdp-histogram.

Overview (`tools/dom-bindings/README.md`) Copy Section

The DOM binding contract

contract.json is the checked-in source for Jint.Browser/Dom/Generated/*.g.cs. It explicitly records every interface, parent, wrapper kind, member body, descriptor, method length, constant, collection accessor and string enum. The emitter reads this file without loading or reflecting over AngleSharp assemblies. A change to a browser binding is a change to this contract, followed by regeneration and review of the generated C# diff. Never hand-edit a .g.cs file.

Regenerate and verify with:

JINT_DOM_BINDINGS=update dotnet test -c Release --project Jint.Tests.Browser/Jint.Tests.Browser.csproj --filter FullyQualifiedName~DomBindingsStalenessTests
dotnet test -c Release --project Jint.Tests.Browser/Jint.Tests.Browser.csproj --filter FullyQualifiedName~DomBindingsStalenessTests

The command-line emitter also accepts --contract tools/dom-bindings/contract.json --output Jint.Browser/Dom/Generated. DomBindingsStalenessTests compares its output byte for byte with the checked-in files and checks that the contract reports no diagnostics. overrides.json and pin.json retain historical decisions and assembly provenance; they neither load assemblies nor constrain benchmark package versions. The one-time upstream assembly extraction switches have been retired. Generation uses contract.json alone, with native Jint.HtmlParser adapters keeping each JavaScript-visible interface and member reviewable.

BindingGenerator.Run loads BindingContract and passes its model directly to Emitter.
The loader rejects unsupported contract versions, duplicate interface/field/member names and a child
listed before its parent. Extraction-era ModelBuilder, Inventory, Conversions and Nullability
sources are not on that path: their attribute-reading rules are not the current generation contract.
Editing overrides.json alone therefore changes no emitted binding.

AngleSharp packages are retained only in Jint.Benchmark for comparisons with Jint.HtmlParser.
ParserDependencyTests enforces this boundary. Binding and parser regression tests use the explicit
contract and expected native tree structures rather than loading an upstream implementation.

Overview (`tools/html-parser-inventory/README.md`) Copy Section

Historical HTML parser replacement inventory (A1)

inventory.lock.json preserves the reviewed AngleSharp migration inventory referenced by the parser
architecture designs. It records the source and binding surface at that stage of the replacement;
it is historical evidence, rather than a current dependency, API or conformance baseline.

The migration scanner and its tests have been retired. Current checks live beside the contracts they
verify: Jint.Tests.Browser/ParserDependencyTests.cs polices the dependency boundary,
DomBindingsStalenessTests verifies generated bindings, public API snapshot tests approve shipped
surfaces, and the WPT suites own their corpus and exclusions. The unsigned fresh-feed consumer under
tools/html-parser-package-consumer checks packaged parser APIs and Browser integration.

Do not refresh this historical lock when changing current code. Run the relevant contract tests instead.

Overview (`tools/html-parser-package-consumer/README.md`) Copy Section

Jint.HtmlParser packed consumer

This unsigned application consumes the newly packed Jint.HtmlParser NuGet package. It has no project
reference, friend access, signing key, or dependency on AngleSharp. The parser-only mode has no engine
dependency. Its own build configuration stops repository-wide MSBuild inheritance. Package source mapping restricts
Jint and Jint.* to the local feed and allows third-party dependencies from nuget.org,
so no Jint package can resolve from nuget.org.
The local-feed paths use forward slashes so NuGet retains the source's mapping identity on Unix as
well as Windows; a restored cache must not hide a broken fresh-package resolution.

The explicit 5.0.0-consumer-smoke prerelease below is preserved by the parser version policy.
Stable Version or PackageVersion inputs instead acquire experimental- (default 0),
even for a Jint GA tag. Use the resulting version in consumer references; do not assume the parser
package version equals the stable Jint/Browser version. This probe supplies acceptance evidence but
cannot by itself close ACC-06 or freeze all public APIs.

From the repository root on macOS or Linux, run:

rm -rf artifacts/html-parser-package-consumer
dotnet pack Jint.HtmlParser/Jint.HtmlParser.csproj -c Release \
  -o artifacts/html-parser-package-consumer/feed \
  -p:PackageVersion=5.0.0-consumer-smoke \
  -p:RestoreSources=https://api.nuget.org/v3/index.json
dotnet restore tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj \
  --configfile tools/html-parser-package-consumer/nuget.config
dotnet run --project tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj -c Release -f net8.0
dotnet run --project tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj -c Release -f net10.0

Each run prints ALL PARSER PACKAGE PROBES PASSED only after checking HTML, XML, strict SVG, fragment
ownership, mutation records/drains, whole-sheet CSS syntax, all owned XPath overloads and result kinds,
typed IDs and imports, namespace contexts and stale bindings, detached attribute axes, and all five
serialization routes including shadow acquisition/selection, templates, output limits and cancellation.
It also checks public DTD processing-instruction metadata, immutable snapshot/clone behavior and
original-input offsets without relocating instructions into DOM children. Live-traversal probes cover
node/attribute identity, character-data edits, live and static range endpoints and contents, adoption,
iterators and tree walkers. These checks replace the standalone D6r6 consumer and run in both the
shared packaged-consumer CI job and its parser-only Native AOT leg.
Clearing the disposable feed and package cache before packing prevents a prior package with the
same version from answering the test. Inspect the actual package dependency list and shipped assets:

dotnet list tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj package --include-transitive
unzip -p artifacts/html-parser-package-consumer/feed/Jint.HtmlParser.*.nupkg '*.nuspec'
unzip -l artifacts/html-parser-package-consumer/feed/Jint.HtmlParser.*.nupkg

The package must contain both lib/net8.0 and lib/net10.0 assets, declare System.IO.Hashing,
include licenses/ValueStringBuilder.LICENSE.txt, and have no Jint or AngleSharp dependency.
The application also checks that its own assembly is unsigned and that it loaded the
Jint.HtmlParser assembly. The package manifest and restored graph are the dependency checks, since
reflection-based assembly-reference enumeration is unsafe in a trimmed Native AOT consumer.

Where a Native AOT toolchain is installed, publish and run one target (replace the RID for the host):

dotnet publish tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj \
  -c Release -f net10.0 -r osx-arm64 -p:PublishAot=true \
  -p:RestoreConfigFile=tools/html-parser-package-consumer/nuget-aot.config
./tools/html-parser-package-consumer/bin/Release/net10.0/osx-arm64/publish/HtmlParserPackageConsumer

The AOT restore config also permits compiler and runtime packs from nuget.org. Its specific
Jint package mappings take precedence over the dependency wildcard, so the parser package keeps
its unique 5.0.0-consumer-smoke version and can only restore from the local feed.

Continuous integration Copy Chapter

The shared html-parser-package-consumer.yml workflow runs from both PR and main builds. Each Linux
job starts with an empty feed and consumer package cache, then packs Jint, Jint.DevTools, Jint.HtmlParser
and Jint.Browser. Its two version inputs cover a prerelease and a GA Browser whose parser remains
experimental. verify_packages.py checks both shipped framework assets, the parser's package policy,
and Browser's exact dependency on the actual parser version before supplying consumer version properties.

The consumer builds and runs on net8.0 and net10.0 with IncludeBrowser=true. This adds a packaged
Browser smoke probe that creates a page, parses HTML, runs script and reads DOM text. For example,
after packing all four packages with Version=5.0.0, run:

python3 tools/html-parser-package-consumer/verify_packages.py feed \
  --version 5.0.0 --framework net8.0 --framework net10.0
dotnet build tools/html-parser-package-consumer/HtmlParserPackageConsumer.csproj -c Release \
  -p:IncludeBrowser=true -p:HtmlParserPackageVersion=5.0.0-experimental-0 -p:BrowserPackageVersion=5.0.0
python3 tools/html-parser-package-consumer/verify_packages.py restore \
  --version 5.0.0 --framework net8.0 --framework net10.0 --browser

Restore verification checks exact versions, framework assets, the source recorded by NuGet and the
SHA-512 of each restored Jint package against the fresh feed. CI then clears the consumer outputs and
cache again, publishes the parser-only probe as Linux net10.0 Native AOT, checks its restore provenance,
and runs the native binary. Trim/AOT analysis warnings fail this parser leg. Browser's general AOT
compatibility remains unclaimed; its integration probe runs under the regular .NET runtimes.

Overview (`tools/whatwg-encoding/README.md`) Copy Section

Encoding Standard data

indexes.json and encodings.json are vendored verbatim from the
Encoding Standard's repository, at commit

a985b62a9b45c17da3e17a9f0a0b4e30c34c4a8a

encodings.json is the machine-readable form of the standard's
names-and-labels table; indexes.json holds the
indexes the legacy encodings decode through. whatwg-encoding-LICENSE.txt
is that commit's LICENSE: the standard is licensed under Creative Commons Attribution 4.0 International and,
in its own words, "to the extent portions of it are incorporated into source code, such portions in the source
code are licensed under the BSD 3-Clause License instead" — which is what the generated tables are.

Both files are checked in unmodified, including their line endings (.gitattributes pins them to LF), so
verifying them is curl plus git diff and nothing else. Only the single-byte indexes are consumed today;
the multi-byte ones are carried along because trimming the file would make that check a judgement call
instead of a comparison.

Regenerating the tables Copy Chapter

generate-encoding-tables.ps1 reads both files and writes
Jint/WebApi/Encoding/EncodingTables.Data.cs — the label
table TextDecoder resolves a label through, and the ushort[128] index each single-byte encoding decodes
through.

pwsh tools/whatwg-encoding/generate-encoding-tables.ps1

The build never runs it. The generated file is committed, regeneration is a manual step, and its header
records the commit above along with the SHA-256 of the exact bytes it was generated from. The script validates
what it reads — 128 entries per index, every code point inside the BMP and never a surrogate, U+0000 unused so
it can mean "unmapped", labels unique and ASCII-lowercase, every encoding's lowercased name among its own
labels — and fails rather than emitting something subtly wrong.

Jint.Tests embeds both JSON files (from here, not from a copy) and checks the generated tables against them:
every label the standard lists resolves to the encoding it names, and all 28 single-byte encodings decode all
256 byte values exactly as their index says. So a regeneration that changes anything is visible either in the
diff or in a failing test.

Refreshing the data Copy Chapter

1. Resolve main in whatwg/encoding to a concrete commit.
2. Download indexes.json, encodings.json and LICENSE at that commit and replace the files here.
3. Update the commit in this file and in $sourceCommit at the top of the script.
4. Re-run the script and commit its output together with the data.
5. Run Jint.Tests. New labels or encodings show up as failures in LegacyEncodingTests — the counts it
   asserts are deliberate, so that an encoding added upstream has to be looked at rather than absorbed.

Overview (`tools/wpt-scoreboard/README.md`) Copy Section

`wpt run` against `Jint.Browser`

A wptrunner product called
jint_browser, and the script that turns the run's wptreport.json into
the published scoreboard
— a page that exists once the first nightly run has written the branch it lives on, and never before.

This is the other web-platform-tests number in this repository, and the difference is the point:

Neither replaces the other. The census is the one an engine change has to keep; the scoreboard is the one
that can be compared with what other engines report, because upstream measured it.

The spike: why this is a product plugin and not `wpt run chrome` Copy Chapter

wpt run chrome cannot drive this browser, and the reason is structural rather than a missing flag.

• wptrunner/browsers/chrome.py calls require_arg(kwargs, "webdriver_binary"), and its browser class is a
  WebDriverBrowser that launches that chromedriver process and talks WebDriver classic to it.
• Its executors (ChromeDriverTestharnessExecutor and friends) reach CDP only through
  chromedriver's goog/cdp/execute extension command — a WebDriver endpoint. There is no
  debuggerAddress capability anywhere in the wpt tree, so there is no supported way to point that product
  at a browser somebody else started.
• Jint.Browser speaks CDP and nothing else. Lightpanda ships a WebDriver front end as well as CDP for
  exactly this reason; this package is the other way of closing the same gap.

So: a custom product. It needs no fork of wpt, because wptrunner.products loads external products from the
wptrunner.products entry-point group —
pip install this package into the virtualenv wpt run uses and wpt run jint-browser … finds it.
wpt run maps the hyphen to an underscore itself, and an unknown-but-loadable product gets
GenericBrowserSetup, which requires no binary and installs no driver.

What is not re-implemented: the harness, the report format, the result conversion, the server, the
manifest, the timeouts, and the decision about whether a subtest passed. wptrunner's own
testharnessreport.js is what the server hands each page, and CallbackHandler +
testharness_result_converter are what turn its output into results. What this package adds is a transport.

How a result gets out of a page Copy Chapter

1. Page.addScriptToEvaluateOnNewDocument installs bridge.js on every
   document. Jint.Browser's PageTarget commits a document by announcing the navigation, swapping the
   engine, re-installing the Runtime.addBinding bindings and then running these scripts — all before the
   document's first inline script — which is the only ordering in which any of this works.
2. bridge.js is upstream's message-queue.js. That file opens by returning if the queue already
   exists, because "another script already set up the testdriver infrastructure"; this is that script. So
   testharnessreport.js still calls add_completion_callback and still pushes
   {type: "complete", tests, status}, unchanged.
3. Instead of handing the item to an asynchronous WebDriver script, the bridge hands it to a
   Runtime.addBinding binding as one JSON string. It captures the binding function and deletes the global,
   so a document that enumerates window does not find the runner's plumbing among its results.
4. Runtime.bindingCalled arrives on the executor's CDP connection; CallbackHandler turns it into the
   tuple testharness_result_converter wants, with the URL the executor navigated to rather than the one
   the page reports — which is what upstream's __wptrunner_url dance exists to get right.

The CDP client is cdp.py over websocket.py,
about 200 lines of RFC 6455 with no dependencies. That is deliberate: wpt run builds its own virtualenv,
and every published CDP client for Python would add a dependency chain to it. The frame codec is unit-tested
over a socket pair, because the two ways it can be wrong — an unmasked client frame and a mis-taken length
branch — both look like the browser hanging up rather than like a bug.

What is deliberately left out Copy Chapter

• Reftests. Jint.Browser renders nothing. JintBrowserRefTestExecutor answers PRECONDITION_FAILED
  with a sentence rather than failing the run or, worse, reporting a pass nothing measured. The workflow
  passes --test-types testharness so one is never reached in practice.
• testdriver.js actions. supports_testdriver is False, so wptrunner skips a test that needs
  one and says why, rather than failing it. Turning an element into a point needs getClientRects inside
  the page, which is real work; the in-process lane already maps test_driver onto the same
  InputDispatcher the Input domain reaches, so this is a gap in the scoreboard rather than in the
  engine. send_message is implemented anyway, so a document that reaches test_driver without the
  manifest flag gets upstream's "not implemented" answer instead of hanging until its timeout.
• HTTPS. Jint.Browser has no way to be told about an extra certificate authority, so a run over wpt's
  pregenerated certificates would fail every https case for the environment's reason. The workflow passes
  --ssl-type=none, and wptrunner then leaves https tests out of the run entirely
  (include_https=ssl_enabled) rather than running them into a wall. Installing wpt's CA into the runner's
  trust store would lift this; it is the obvious next step and is not in v1.
• --untrusted. The nightly does not pass it. BrowserOptions.ForUntrustedContent applies
  UntrustedCodeLimits.Default to every page engine — one second per engine entry, 50 000 statements,
  10 000-element arrays, recursion depth 64, a 250 ms regex budget — and the command line has no switch for
  any of the five. Those are the right numbers for a page nobody vouches for and the wrong ones for a
  conformance measurement: a scoreboard taken under them would be a report on the hardened profile. What is
  served is vendored, pinned content on loopback.

Running it yourself Copy Chapter

The nightly is .github/workflows/wpt-scoreboard.yml and it is the specification; this is the same thing
by hand.

/* Detailed source-code truncated for AI context efficiency. */

What the run costs, and the flag that decides it Copy Section

The wall time is dominated by the cases that fail by not reporting: a document that never completes
costs its whole timeout, and a <meta name=timeout content=long> file's timeout is 60 seconds.
html/semantics/scripting-1/the-script-element/moving-between-documents/ is 52 of those, and every one of
them waits for a message posted by script running inside an `` — and iframes run no script in this
version, by design (docs/design/headless-browser.md keeps that for a later phase), so the harness never
finishes — so that one directory is most of an hour, and will be until iframes run script.

There is therefore no --timeout-multiplier, and the reason is not only cost. Every per-test timeout in
the corpus is the test author's, and wpt.fyi's published figures are taken at the default of 1; a scoreboard
measured at 2 would be systematically more generous than the numbers it invites comparison with. Raising it
doubles exactly the cases that are already failing and changes nothing about the ones that pass.

If the nightly gets too long Copy Section

The run restarts the test runner after almost every test, and that is not a defect: restart_on_unexpected
defaults to on, this repository ships no wpt expectation metadata, so every failure is unexpected. It
costs about a second per failing test — measured at roughly 15% of the wall time. --no-restart-on-unexpected
removes it, and is safe here for a reason that is specific to this browser rather than general: a navigation
already disposes the previous document's engine and cancels everything it had in flight, and a runner restart
only mints a new page target rather than a new process, so the isolation the flag buys is isolation the next
Page.navigate gives anyway. It is not passed today because upstream's default is what a reader expects.

`wpt-config.json`, and why it exists Copy Section

It is copied into the checkout as its config.json, which is the override
TestEnvironment.build_config reads before it starts the servers. All it does is null three ports out:
ConfigBuilder._get_ports skips the bare https and wss schemes when SSL is off, but not
https-local, https-public or h2. Left in, those three try to start with no certificate and the whole
environment dies with Servers failed to start: https-local:8445, https-public:8446. The four .h2. test
files are excluded by name in the workflow for the same reason, so that they are absent rather than internal
errors.

On a machine whose hosts file you cannot write Copy Section

wpt run refuses to start without the hosts entries, and that refusal is right — a third of fetch/api and
xhr need a second origin. If you cannot have them, you can get a run out of the tree by pointing the
server at a wildcard-loopback domain in the same config.json, and calling wptrunner directly rather
than through wpt run:

{
  "browser_host": "web-platform.localtest.me",
  "alternate_hosts": { "alt": "not-web-platform.localtest.me" },
  "ports": { "https-local": [null], "https-public": [null], "h2": [null] }
}

Every name under localtest.me resolves to 127.0.0.1 in public DNS. It is correct and it is slow —
every subresource is a DNS round trip, which multiplies a page load by about ten — so it is a way to
develop, never a way to measure.

The tests Copy Chapter

tests/ runs under pytest and is what the workflow runs before anything else.

• test_websocket.py — the frame codec over a socket pair. No browser, no server, no environment
  variables; it always runs.
• test_scoreboard.py — a report in, a page out. Likewise.
• test_executor_smoke.py — the whole path against a real jint-browser serve, on one document with three
  passing subtests and one that fails on purpose. It needs WPT_ROOT (a wpt checkout, for testharness.js
  and wptrunner's report script) and JINT_BROWSER_COMMAND (how to start the built tool), and skips
  naming the missing one when it does not have them.

WPT_ROOT=$PWD/wpt \
JINT_BROWSER_COMMAND="dotnet $PWD/artifacts/bin/Jint.Browser.Tool/release_net10.0/Jint.Browser.Tool.dll" \
  .wpt-venv/bin/python -m pytest tools/wpt-scoreboard/tests -q

What this is pinned against Copy Chapter

wptrunner's external-product contract is young: products.Product, get_all_products() and the
wptrunner.products entry-point group are what product.py builds against, and Product is constructed
directly rather than through the older __wptrunner__ dict so that a field it grows is a TypeError here
rather than a silent default. The workflow always checks wpt out at the corpus pin, so an upstream change to
that contract arrives with a deliberate pin bump and not on a random night.

Overview (`Jint.Tests.HtmlParser/Html/TreeConstruction/README.md`) Copy Section

Bounded HTML tree fixture census

Html5libSubsetTests.cs transcribes 14 complete-document #data / #document
cases from html5lib/html5lib-tests/tree-construction at commit
9329e64694e7835d0dcff9811e22856ef6ad16f9 (the last revision before those
files moved to WPT). Case IDs name the source file and one-based #data ordinal.
The original license is copied in UPSTREAM-LICENSE.txt. The subset tests assert
the tree, while tokenizer and tree diagnostic tests assert their separate codes.
The independent H4 algorithm reference is the HTML Standard tree construction
snapshot updated 2026-09-22.

Executed: 14 of 14 selected historical document cases. H7a foreign dispatch is
covered by authored native-tree fixtures in HtmlForeignTreeTests and the complete
37 SVG tag, 58 SVG attribute, and 11 foreign namespace adjustment rows in
HtmlForeignAdjustmentTests. Their primary source is the
WHATWG HTML source at 2f441941fc523877bd9d5cd7de3b91a81a00ca2e,
inspected 2026-09-25, specifically the tree-construction dispatcher, creating and
inserting nodes, and foreign-content rules. These authored fixtures are not WPT
passes and do not increase the historical corpus census. They cover namespace
identity, integration exceptions and accepted-token encoding facts, breakouts,
foreign scripts, diagnostics, CDATA context, every short split at quotas 1/3/large,
destination ownership/IsValue, and charged resumable long-name scans. No
ForeignContent stop remains reachable; contextual fragments remain H7b and
active parser scripting remains H8. Frameset and tail modes are covered in
HtmlFramesetTreeTests against the HTML Standard updated 2026-09-25. Ordinary templates,
content patching, and applicable declarative-shadow parsing are covered in
HtmlTemplateTreeTests and HtmlTemplatePatchingTests against the current HTML Standard.
No Templates stop remains reachable. Default standalone declarative-shadow permission is false;
internal calling algorithms can select it and supply cached engine-free Browser host facts.
Patch coverage includes native PI pseudo-attributes, ordinary descendant and sibling scope,
actual fragment/template ownership, captured removals from live parents, moved markers, close
versus EOF, quota-one work scaling, every short fragment split, and coherent cancellation or
notification failure around atomic native removal. Declarative coverage uses real shadow roots,
flags/registry ownership, actual fragment hosts, permission/host/existing-root fallback, and
host-provider lookup gates and original infrastructure exceptions. This is authored native
coverage, not an expansion of the historical WPT census. Atomic native work boundaries and the
public HTML promotion amendment are recorded in
the promotion checkpoint.
HtmlTableStructureTests and HtmlTableTextTests cover H5a/H5b
against the 2026-09-22 HTML Standard; the historical corpus pin above is comparison
evidence, not the rule for a changed algorithm. Table text tests cover pending runs,
foster locations, input splits, quota continuations, and coherent cancellation.
The original subset deliberately excludes historical PI cases whose bogus-comment
expectations conflict with the current Standard's processing-instruction tokens,
and select cases whose insertion rules changed. Current-spec PI behavior is
asserted independently in ProcessingInstructionsRetainPlacementAndCase;
current select trees are asserted in HtmlSelectTreeTests. Fragment-context
select cases remain with H7b.

H7b contextual fragments use the same native session/tokenizer/tree builder with a
private parser document, a synthetic HTML stack root, and a target-owned detached
root insertion fragment. HtmlFragmentTreeTests contains 57 authored cases against
HTML Standard §13.4 and the tree-construction rules inspected 2026-09-25. This is
an internal seam; it does not promote MarkupParser or complete Browser cutover.
The matrix covers HTML/table/select/template contexts, initial text states without
an appropriate end tag, SVG/MathML integration and CDATA, all document modes,
form ancestry, template/shadow targets, script flags/source metadata, ownership and
formatting reconstruction/adoption including IsValue. Short contexts/text/foreign
cases run every split at quotas 1/3/large. Seven structural differential cases use
pinned AngleSharp 1.8.2 only for conforming intersection behavior; current select,
PI and patch rules retain independent expectations. No existing corpus pin or
exclusion changed. Document form-pointer association now resolves roots and commits
fresh insertion cooperatively; quota-one, deterministic depth-plus-control scaling
and host-adoption cases cover the cache invalidation contract.

Overview (`docs/benchmarks/binding-comparison-2026-09/README.md`) Copy Section

D0.3: reproduced DOM binding spike comparison

Two independent complete hosted runs reproduce lower measured costs for the small hand-shaped binding
spike than for AngleSharp.Js reflection on the three DOM workloads. This completes the measurement and
scoped conclusion for campaign #3575 D0.3, whose harness
was tracked in #3898.

This is an end-to-end comparison of two explicitly different embedding paths. It does not isolate the
causal benefit of shapes, measure the production generated browser bindings, or establish equivalent-browser
startup savings. The interpreter versions and binding surfaces differ. The cold interpreter control makes
the setup difference especially visible; controls are reported without subtraction.