Re-check shipping Safari JSPI; track JSC multi-memory (WebKit lane cap)

[lann]

Two WebKit follow-ups from the M3 browser lanes:

1. Shipping-Safari JSPI re-check. The compatibility notes record "Safari: JSPI in Technology Preview only, flagged" — but M3 found JSPI working unflagged on playwright's WebKit (WPE 26.5, linux): Suspending/promising present, real suspend/resume round trip green. Re-check against shipping Safari on macOS before relaxing the stable-Safari exclusion (docs/architecture.md §3).

2. JSC multi-memory is the actual WebKit lane cap. 58 commands fail at WebAssembly.Module compile ("there can at most be one Memory section for now") + 111 cascades — the canonical ABI routinely needs >1 memory per core module (transcoding, cross-component copies, realloc into another instance). Engine gap, not a host defect: the same components run on V8 and SpiderMonkey. Track JSC's multi-memory implementation; when it ships, harness/browser/expectations/webkit.ts should collapse toward Chromium/Firefox parity (stale-delta detection will force the overlay update).

[lann]

Scoping datum from comparing against jco's WebKit story (polymorph-webcrypto runs a jco-transpiled component on playwright WebKit in CI — their WPT parity leg, macOS job):

• jco never needs multi-memory: it emits single-memory core modules and does every canonical-ABI copy (host boundary AND cross-component) in generated JS that holds the WebAssembly.Memory objects and copies via typed arrays. multiMemory is an opt-in optimization in TranspileOpts (default false; polymorph never enables it). Multi-memory is only a module-validation concept — N memories at JS scope is baseline-legal everywhere.
• Their leg also confirms JSC ships JSPI (their in-page harness hard-fails without WebAssembly.Suspending and the leg gates green) — independent corroboration of the M3 WPE 26.5 finding.

Consequence for deltic: the multi-memory cap bites exactly where FACT fused adapters carry memory-crossing payloads — i.e. cross-component calls in compositions (and the suite's inter-component cases). Single-component + host-module workloads (the consumer profile of the iroh endpoint and the ports as run today) generate no FACT adapters, so they should be unaffected on WebKit; worth verifying empirically when a consumer browser leg lands.

If Safari coverage of composed workloads becomes a requirement before JSC ships multi-memory, the escape hatch would be an alternative adapter strategy (host-mediated copies) for the callback-ABI profile — frame-rule-legal there because nothing suspends beneath a cross-component call. That is a whole second backend in the jco problem-space direction; default remains wait-for-JSC.

[lann]

JSC multi-memory: landed upstream, default-ON in playwright's next WebKit roll — WebKit reaches effective parity. (Operator tip: JSC_useWasmMultiMemory=1.)

Measured 2026-08-09, linux-arm64:

• webkit-2336 (playwright 1.62.1 stable, our pin): JSC_useWasmMultiMemory exists in the option table but is inert — two-memory modules still rejected with the flag set. Not an env-delivery problem: the route was verified live (JSC_useWasm=0 kills WebAssembly entirely through the same launch({ env }) passthrough the lane driver uses). The option is a stub in this build.
• webkit-2342 (playwright 1.63.0-alpha-2026-08-07): multi-memory works and is enabled by default — no flag needed. Two declared, two imported, and memory.size 1 / memory.copy 1 0 all compile and execute. JSPI still green ({suspending, promising, roundTrip} = true).
• Full conformance lane vs webkit-2342: 1395 / 1349 executed / 1248 passed / 0 failed / 101 xfail / 41 / 5 — up from 1075 passed on 2336. 173 of the 175 multi-memory overlay deltas collapse. The only WebKit-specific residuals are 2 trap-message-wording commands (async/big-interleaving-test.wast:836, async/builtin-trap-poisons-instance.wast:9 — JSC says "Unreachable code should not be executed"), the same tolerated wording class as Firefox's single variance (docs/architecture.md §1). Everything else in the xfail column is the Deno lane's own 99, identical classification.

Repro: install webkit from the alpha into a scratch cache, stage the Ubuntu-24.04 libs (copy webkit-2336/minibrowser-wpe/sys/lib/ extras into the new bundle), symlink webkit-2336 -> webkit-2342 in that cache so the pinned driver launches it, then PLAYWRIGHT_BROWSERS_PATH=<scratch> PLAYWRIGHT_SKIP_VALIDATE_HOST_REQUIREMENTS=1 deno run -A tools/browser/run-lane.ts webkit.

Action when playwright 1.63 goes stable: bump the pin, collapse harness/browser/expectations/webkit.ts to the 2 wording entries (the stale-delta detector will demand exactly this), and promote the lane from best-effort. The shipping-Safari re-check (item 1 of this issue) remains open — Apple's stable channel is a separate question from WebKit trunk.

[lann]

Follow-up (6a73409): engine trap-wording normalization moved out of the runtime into the harness matcher (TRAP_MESSAGE_EQUIVALENTS), with rows for all three engine spellings of the core unreachable trap — including JSC's capitalized "Unreachable code should not be executed", which the substring fast path can never match.

Re-measured against the webkit-2342 scratch cache after the change: 1395 / 1349 / 1250 passed / 0 failed / 99 xfail / 41 / 5 — byte-identical to the Deno lane. Zero WebKit-specific deltas remain (the earlier "2 wording residuals" are gone).

So the playwright-1.63 pin bump now collapses harness/browser/expectations/webkit.ts to a truly empty overlay, and the same commit already emptied Firefox's (1250/0/99 there too). At the bump, all four lanes — Deno, Chromium, Firefox, WebKit — should report identical tables.

[lann]

The engine-canary escalation path discussed in this thread is now its own tracked deliverable: #22 (SpiderMonkey-nightly + JSC-trunk shell lanes). Two channel facts found en route that improve on earlier statements here: Mozilla publishes per-nightly jsshell zips including linux-aarch64, and WebKit's buildbots publish daily trunk JSC-only builds for linux-x86_64 at webkitgtk.org/jsc-built-products (today's 318852@main) — so the canary needs no build pipeline in CI. For this issue specifically: the canary watches JSC trunk continuously, so the playwright-pin-bump → empty-overlay transition (and any post-multi-memory JSC regressions) get advance warning.

[lann]

The canary lanes (#22, now closed) turned this issue's trunk measurement into a standing weekly gate: the first canary.yml run has JSC trunk (318852@main) at exact Deno-lane parity — 1250/0/99, zero deltas, full capability matrix (JSPI round trip, multi-memory, wasm-GC, EH, memory64, tail-calls, relaxed-simd) — via the jsc-built-products channel, independent of playwright. Remaining here: the shipping-Safari re-check (item 1) and collapsing the WebKit browser overlay to empty at the playwright ≥1.63 pin bump; the canary will flag any trunk regression in the meantime.

[lannbot]

Upstream citation for the multi-memory flip, for the record: WebKit/WebKit@fcd66f17f455 — "Enable wasm multimemory feature flag" (https://bugs.webkit.org/show_bug.cgi?id=319389, canonical 317636@main). Switches --useWasmMultiMemory on by default and drops the single-memory validation tests. Consistent with both prior measurements in this thread: it predates the canary's parity run at 318852@main, and explains webkit-2336 (pinned) carrying the option as a stub vs webkit-2342 (1.63-alpha roll) having it default-on.

Pin-bump status: playwright stable is still 1.62.1 (1.63.0 is in daily alphas as of 2026-08-21), so the remaining action here — bump the pin, collapse harness/browser/expectations/webkit.ts to empty, promote the lane — is still waiting on the 1.63 stable release.

[lannbot]

STP milestone: both engine requirements now ship in Safari Technology Preview. STP 250 (2026-08-13, macOS Golden Gate + Tahoe) is the first STP carrying multi-memory — its release notes list "Added support for multiple memories in a single WebAssembly module" citing exactly the flip commit above (317636@main falls inside its 317507@main…317934@main range): https://webkit.org/blog/18191/release-notes-for-safari-technology-preview-250/. Same release also brings relaxed SIMD (317549@main). JSPI is present in STP too (operator-confirmed; no STP release note ever named it — WebKit flipped it in trunk quietly, consistent with M3 finding it unflagged on WPE 26.5 while external compat tables still said "TP, flagged").

So the full deltic engine floor (JSPI + multi-memory) is now on Apple's own preview channel, not just trunk/WPE builds. What this issue still gates on is unchanged but now clearly time-bounded:

• Item 1 (stable-Safari re-check): STP → stable typically lands in the next annual Safari release; the architecture.md §3 stable-Safari exclusion stays until then.
• Overlay collapse: still waiting on playwright 1.63 stable (pin bump), independent of Apple's channels.

docs/architecture.md's engine table + risk register updated with the STP 250 datum (PR to follow).