x.com shows "Something went wrong" for minutes before the app appears (tracking)

[codymullins]

Loading https://x.com/nasa in the Starling browser first shows X's fallback page — "Something went wrong, but don't fret — let's give it another shot. Try again ⚠️ Some privacy related extensions may cause issues on x.com." The real app only appears minutes later. This is a tracking issue for the root causes, all verified on 2026-06-10 with repros on the real engine and Chromium baselines.

The mechanism

x.com's served HTML ships a hidden error panel (#ScriptLoadFailure, hidden by .r-hvic4v{display:none}) and three <script defer> bundles. Each bundle sets window.__SCRIPTS_LOADED__[name] at the end of its own execution. An inline watchdog runs at DOMContentLoaded (or immediately if document.readyState !== 'loading') and un-hides the panel when __SCRIPTS_LOADED__['main'] is unset. Per the HTML spec, defer scripts run before DOMContentLoaded, so in Chromium the watchdog only fires on a genuine load failure. In Starling it fires on every load.

Why the panel shows (each alone is sufficient — all three must be fixed)

• document.readyState is always "complete" — implement the document readiness state machine #70 — document.readyState is a hardcoded "complete". The watchdog skips waiting for DOMContentLoaded entirely and runs during the inline-script phase.
• Interactive page load fires DOMContentLoaded before <script defer> runs (HTML spec inversion) #71 — the interactive path fires DOMContentLoaded before any <script defer> executes. Even with document.readyState is always "complete" — implement the document readiness state machine #70 fixed, the watchdog's listener still fires before main.js runs.
• ScriptFetcher turns large defer scripts into async scripts — breaks script-order guarantees (band-aid for slow JS execution) #72 — ScriptFetcher reclassifies large defer scripts as async (a band-aid for slow JS execution). Even with Interactive page load fires DOMContentLoaded before <script defer> runs (HTML spec inversion) #71 fixed, the bundles would still land after DOMContentLoaded.

Why the app takes minutes to appear

Bundle execution happens in the post-paint deferred pump and takes 2–2.5 minutes at current Starling JS engine speed (deferred.summary: … pump2=110668ms total=147706ms). That perf work is tracked separately (inline caches / hidden classes, on an unmerged branch). When main.js finally runs, React mounts into #react-root and replaces the panel.

Why the booted app is degraded (found on the same boot)

• Starling JS compiler: false ReferenceError for captured let/const declared in catch blocks or switch cases #73 — Starling JS compiler: phantom temporal dead zone cells for captured let/const in catch blocks and switch cases (false ReferenceError, V8-clean repro).
• Starling JS parser: valid regex Unicode property escapes (\p{Mark}) are rejected — whole scripts fail to parse #74 — Starling JS parser: valid regex Unicode property escapes rejected — kills whole webpack chunks.
• Starling JS parser: comma expression inside a template-literal substitution fails to parse #75 — Starling JS parser: comma expression in a template substitution fails to parse — kills a chunk.
• Starling JS parser: 'in' operator inside parentheses in a for-loop head is rejected #76 — Starling JS parser: parenthesized in in a for-loop head rejected — kills a chunk.
• document.currentScript is not implemented — dynamically injected scripts that read it crash (breaks Google sign-in on x.com) #77 — document.currentScript missing — Google sign-in script crashes on its last statement.

The parser failures (#74–#76) share one blast-radius pattern: one parse error kills every webpack module in a chunk. Webpack caches the half-evaluated requiring module, which later surfaces as the deterministic Cannot access a lexical binding before initialization error seen from main.565e4e9a.js on every load.

Log noise and a real race found on the same boot

• Navigating away floods the log with "Uncaught … The operation was canceled." — cancellation escapes into the uncaught-error reporters #78 — teardown cancellation misreported as 36 "Uncaught … The operation was canceled." errors (host log only, invisible to page JS).
• Page JS and layout run on two threads at once — ScrollStateStore guard trips in DEBUG, silent data race in Release #79 — page JS and layout run on two threads at once on the interactive path. The ScrollStateStore guard catches it in DEBUG. Release races silently.

Suggested order

#70 + #71 (+ #72) remove the error page. #77, #73, and #74–#76 clean up the booted app. #78 and #79 are engine hygiene and correctness, with #79 the deeper architectural one.

Full investigation details (timelines, repro harnesses, Chromium baselines) are in the linked issues.