Seven defects a real application hits before it renders

[pathscale]

Seven defects, all found by driving the fleet's built sites through the headless host, and every one of them invisible to the tests either repository had. Collected into a single pull request because they release together: a workspace version bump is the trigger, and no consumer wants seven of them.

Ordered by how early a page hits them.

The engine could not reach a TLS 1.3 server

Every endpoint-libs backend in the fleet is TLS 1.3 only, and macOS native-tls offers a TLS 1.2 ClientHello with no supported_versions extension. The handshake is refused before a byte of HTTP: peer is incompatible: SupportedVersionsExtensionRequired.

Measured against auth-dev.honey.id, api-dev.honey.id, auth.honey.id, api.honey.id and api.support.cafe. The one fleet backend the engine could reach, api.crates.vip, is the one where Fly terminates TLS rather than the app. rustls also brings rustls-platform-verifier, so trust anchors come from the operating system rather than a bundle compiled in.

A page received a JavaScript engine with no web platform around it

boa_runtime implements URL, TextEncoder and TextDecoder and nothing registered them; only Console was.

@solidjs/router constructs a URL during module evaluation, so a router-based application does not break when you navigate — it throws before the first component renders. A blank page and one log line naming the entry chunk, which is why this survived so long.

URLSearchParams is still missing and URL.searchParams still throws "not implemented" from boa_runtime itself. Both belong upstream in the fork.

A real render ran out of call frames

Boa defaults to 512 nested calls and a 10240-slot value stack, which at roughly seven slots a frame is what actually runs out first. A Solid application renders its component tree as nested calls and threads each through the reactive graph's owner chain, so depth follows page nesting rather than anything an author would call recursion.

support.cafe's /login threw RuntimeLimitError part-way through the render, leaving 15 nodes where there should be 87. It is not catchable: it unwinds the execution rather than arriving as an exception, so the page's error boundary never sees it.

	deepest frame reached
defaults	511
call limit raised only	1462
both raised	8191

Both limits move together. Raising one alone moved the failure to 1462 frames and reported "reached the maximum stack size", which names the wrong thing. Runaway recursion still stops, and runaway_recursion_still_stops pins that.

An on<event> handler died while its element lived

The JS wrapper cache is weak and an on<event> handler was a property of the wrapper, not of the node. A page that created an element, wired it up and dropped its own reference lost the handler to the collector while the element was still in the document.

Every CDN loader is that shape: create a script, set onload, append it, wait on the promise the handler resolves. Measured on nofilter.io's bootstrap — the bundle was fetched and ran, 568 nodes were built, and only the load acknowledgement was dropped. The loader never removed its own body{display:none} and the site read as one that renders nothing. A small script loaded fine, which is what made it look like a size limit.

on<event> is now an accessor on the node prototype, and assigning one roots the wrapper for as long as the node is in the document. A detached node is deliberately not rooted, or this would keep alive exactly what the weak cache exists to release. error joins the event list; it was missing, so 'onerror' in el was false.

getContext did not exist, so a guard never got its turn

@pathscale/ui's metal-border effect asks a canvas for WebGL during render and already carries the guard for not getting one. The method did not exist, so the call threw TypeError: not a callable function before the ?? could run. Under Solid 2 an error with no boundary above it halts the reactive system permanently, so consulting.parcle.ai painted once and then answered nothing.

Null is not a stub standing in for a canvas implementation: it is what the specification says an implementation answers for a context identifier it does not support.

A page could not handle its own form submission

Pressing a submit button called submit_form directly, and Enter in a form's only field did the same. No submit event was dispatched, so a page's handler never ran and preventDefault had nothing to prevent — apply_generated_text_input_event carried a TODO saying so.

Measured on 24x.ai's sign-in: pressing Continue left for /login?username=abc and came back with the field empty and the step reset. The press now dispatches a cancelable, bubbling submit and the submission is that event's default action.

Three tests, because two of them pass for the wrong reason alone.

Anchors had no href IDL property, so client-side routing was impossible

element.rs defined accessors for src, value, checked, type and the rest, and never for href. a.href read undefined; only getAttribute("href") worked.

@solidjs/router 2.0 exports no link component. It intercepts in-app navigation with a document-level click listener that reads a.href and hands it to new URL(href) with no base. With href undefined the listener returned at its own guard before reaching preventDefault, so every in-app navigation became a full document load: a fresh script context, a re-bootstrapped application, and every WebSocket the page held closed with it.

Measured on honey.id after the fix: a navigation that had been a 25-second timeout became 111–268ms, and a suite of 103 checks across roughly twenty pages now runs on one document load.

🤖 Generated with Claude Code