v0.1.14314 Aug 2026·Rendering, JavaScript & JIT, Privacy & Shields

Unmodified Puppeteer drives the engine end to end

The DevTools floor this scorecard has named for months is bridged: a stock, unmodified copy of Puppeteer - the automation library a large share of the web's testing and scraping runs on - now drives the engine through a full page lifecycle over the WebSocket protocol transport. Connect, open a page, navigate, read the title, query elements, run functions against them, wait for a selector, click a button and see the page react, read the content back, navigate again: every step answered by the engine's own protocol surface, verified by a twelve-step probe script shipped in the repo. Getting there took three real JavaScript language fixes (rest parameters in arrow functions, calls and constructors crossing the eval boundary, named class expressions binding their own name) plus protocol work (awaitPromise, unique execution context ids, per-navigation loader ids) - each found by running the real client and fixing exactly what it tripped on. The JavaScript language aspect moves 82 to 83, DevTools moves 45 to 50, and the overall moves 56 to 57 - the first overall move since the WebAssembly release, earned by the floor the plan named.

Parity with the reference browser

74overall, as of v0.1.343

Web APIs / DOM surface42

Security architecture66

GPU / graphics acceleration68

DevTools / extensions72

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

What changed 6 changes

JavaScript & JIT	Rest parameters now work in arrow functions: (...args) => f(...args) threw "arguments is not defined" because the old desugar built the rest array from the arguments object, which arrows do not bind. Rest parameters are now first-class marked parameters the VM binds directly from the call, in every function form - arrows, methods, constructors - with fn.length correctly excluding them. Puppeteer's injected utilities are written exactly this way, which is how the gap was found.
JavaScript & JIT	Calls and constructors now cross the eval boundary correctly in every direction. Code compiled by eval and code compiled by the surrounding program live in different bytecode arrays, and calling or constructing across that line silently returned undefined for several shapes - new C() inside eval-compiled code being the loudest. Every crossing now runs the callee against its own array, including constructors (with correct return-object semantics) and program-compiled functions invoked from inside eval'd code.
Rendering	A named class expression binds its own name inside its body, so the self-referential factory pattern works: c = class t { static create() { return new t() } }. Puppeteer's injected Deferred is written exactly this way and threw "t is not defined".
JavaScript & JIT	The protocol layer honours awaitPromise on Runtime.evaluate and Runtime.callFunctionOn: an async result is unwrapped to its settled value (a settled engine promise unwraps inline; a pending one is retried across engine turns, each of which drains microtasks), instead of handing the client a useless promise handle it would probe forever.
Rendering	Execution context ids are unique per announcement and loader ids are fresh per navigation, as a real browser's are. Reusing them made the client see phantom new contexts (so its wait tasks re-ran against stale handles) and made every second page.goto wait forever for a navigation it thought had not started.
Privacy & Shields	The probe scripts ship in the repo (shell/scripts/cdp-puppeteer-full.mjs and cdp-raw-trace.mjs) so the claim is reproducible against the live app: twelve lifecycle steps driven by stock puppeteer-core over ws://127.0.0.1. The CDP socket itself stays strictly opt-in (FLOATI_CDP_PORT) and loopback-only - a privacy-first browser does not open a listening socket by default.