diff --git a/FIDELITY.md b/FIDELITY.md
index b854d79..000eea9 100644
--- a/FIDELITY.md
+++ b/FIDELITY.md
@@ -18,6 +18,18 @@ The committed PNGs under `testdata/renders/` back every claim here. Reproduce
 them with the commands at the bottom. The measured-vs-Chrome numbers live in
 [`bench/REPORT.md`](bench/REPORT.md).
 
+## 2026-09-09 (round 71) — two real, independently-confirmed gaps in dynamic script loading closed (`onload`/`onerror` never existed on any element; a script appended during timer-draining could be silently stranded, never run) — neither alone closes react.dev's own `ChunkLoadError`, whose remaining root cause is a genuinely deeper, separate simplification flagged for a future round, not attempted here (engine#160)
+
+No fresh issue was filed this round (checked `gh issue list` again). en.wikipedia.org's own diffuse whole-page offset reconfirmed (not rediscovered) as the same external "Wiki Loves Monuments" banner noise from rounds 63/64/70. Continued round 69/70's `Engine.JSLog`-sweep methodology instead of a fresh visual scan, and dug into react.dev's own recurring `ChunkLoadError: Loading chunk 809 failed. (timeout: …)` — present in every prior sweep this session but never individually root-caused, always folded into the page's already-known, much bigger "reskin gap."
+
+- **Root-caused with direct, temporary Go-level instrumentation** (added, used, then fully removed before shipping — confirmed via `git diff`) rather than guessed from the minified bundle: traced the failing chunk's own dynamically-created `<script>` element all the way through — `document.createElement('script')` DOES run, `document.head.appendChild(...)` DOES attach it to the real tree with the correct `src` — but its fetch is NEVER even attempted (zero matching calls into this engine's own script-fetch function). Two separate, confirmed defects surfaced along this trail:
+  1. **`onload`/`onerror` did not exist as properties on ANY element** — webpack/Turbopack's own classic chunk-loading helper sets both directly on a dynamically-created `<script>` (never via `addEventListener`), so even if the chunk HAD loaded, its own promise would never have settled. Fixed by wiring both generically in `defineElement`, backed by a new `binder.onHandlers` map that lets a later assignment replace (not stack with) an earlier one — the correct IDL-event-handler-attribute semantics — implemented as a registered listener under the hood so `dispatch` needed no separate code path. `runScripts` now also dispatches "load" on a script that fetched-and-ran (regardless of whether its own top-level code threw — a real browser reports that separately via `window`'s error event, not the element's own) and "error" specifically when the FETCH itself fails.
+  2. **A dynamically-injected `<script>` created inside a timer callback could be silently stranded, never run at all.** `Session.RunPending` decided its "did anything happen" signal from `runScripts` alone, called BEFORE `drainTimers` — but the standard chunk-loading idiom (`document.createElement('script'); s.onload=...; s.src=chunkURL; document.head.appendChild(s)`) runs from EXACTLY such a timer callback, so the check always ran too early to see it. The caller (`dynamic.go`'s settle loop) reads a false "ran" as "nothing left to do" and stops iterating — so the freshly-appended script, sitting correctly in the DOM, was simply never picked up. A first attempt at the fix (calling `runScripts` a second time within the same `RunPending` call) over-corrected: it broke `TestSettleFixpointCap` by running a whole SYNCHRONOUS self-replicating script chain's next TWO generations in one pass instead of one per outer settle iteration. Fixed instead by having `RunPending` check, after `drainTimers`, whether any unexecuted `<script>` now exists (`hasPendingScripts`) — reporting "there is more to do" without actually running it inline, preserving the existing one-generation-per-outer-pass pacing; the NEXT `RunPending` call (from the settle loop's next iteration, exactly as it already does for any other case) is what actually executes it.
+- **Honestly, neither fix — even together — closes react.dev's own visible `ChunkLoadError` symptom**, and this was verified directly rather than assumed: re-running the exact same instrumentation after both fixes still shows zero fetch attempts for the chunk. The most likely remaining cause (not fixed this round, flagged as a real, separate, deeper issue): this engine's `setTimeout` binding discards its own delay argument entirely, draining every timer job in pure FIFO order regardless of requested delay — so a bundler's own internal "give up after 120 seconds" safety-net timeout races (and structurally always wins) against the chunk's own near-instant real fetch, an architectural simplification affecting the whole timer model, not a narrow one-round fix.
+- Added `TestSessionInjectedScriptOnloadAndOnerrorFire` (covering both outcomes: a script that fetches-and-runs fires `onload`, one whose fetch fails fires `onerror`, and never the wrong one) and `TestSessionRunPendingReportsPendingScriptAppendedDuringDrainTimers` (a focused white-box test exercising the exact "runScripts finds nothing, but this call's own drainTimers appends a script" ordering, since constructing that exact interleaving through real page HTML alone proved impractical). Both git-stash-confirmed to fail with the exact predicted symptoms when their respective mechanism is reverted. `TestSettleFixpointCap` (the test the first, over-corrected fix attempt broke) re-confirmed still green. All five gated packages re-checked against their floors (css 99.5%, layout/paint/paginate 100.0%, dom 98.1%) — unaffected, `js` isn't itself coverage-gated.
+- **Bench flat on react.dev (0.6126→0.6126, exactly unchanged) — correctly predicted in advance, not a surprise**: confirmed directly via the same instrumentation that the chunk still never fetches, for the separate, deeper reason above. Other corpus movements this run (en.wikipedia.org, developer.mozilla.org, news.ycombinator.com, tailwindcss.com) are consistent with this harness's own already-documented sources of noise — external promotional/ad-banner presence toggling for the first two, and HN's own live, constantly-rotating front page plus its previously-documented diffuse font-metric spacing for the third (checked directly via a side-by-side crop: same stories, same ranking, no attributable rendering difference) — none plausibly related to this round's script-loading-specific fixes.
+- No fresh issue filed, no PR/round-number collision — predicted #160 confirmed via `gh pr list` both before and after pushing.
+
 ## 2026-09-09 (round 70) — `document.currentScript` was hardcoded to always return null, so a bundler's own base-URL detection came back empty for every chunk load — found live on tailwindcss.com's Turbopack runtime, 10 failing script executions closed with one fix (engine#159)
 
 No fresh issue was filed this round (checked `gh issue list` again). A visual scan of en.wikipedia.org's own montage — still the corpus's worst page by a wide margin — traced its whole-page diffuse vertical offset directly to the SAME already-documented external-content-variability culprit as rounds 63/64: Chrome's fetch this run happened to include the intermittent "Wiki Loves Monuments" promotional banner again, shifting everything below it down by a constant amount; correctly recognised as noise, not chased further. Pivoted to a fresh `Engine.JSLog` sweep (round 60/69's own methodology) instead, which turned up no new panics but did surface a cluster of 10 repeated script-execution failures on tailwindcss.com that hadn't been individually investigated before: `Error: chunk path empty but not in a worker`, once per lazily-loaded Turbopack chunk.
diff --git a/bench/REPORT.md b/bench/REPORT.md
index ff322cb..52629be 100644
--- a/bench/REPORT.md
+++ b/bench/REPORT.md
@@ -2,7 +2,7 @@
 
 <!-- AUTO-GENERATED: this header, the results table and the montage list are regenerated by `go run ./cmd/compare`. The hand-written analysis below the BEGIN ANALYSIS marker is preserved across re-runs. -->
 
-**Generated:** 2026-09-09 13:53 UTC  
+**Generated:** 2026-09-09 20:02 UTC  
 **Viewport:** 1024×768, device-scale 1  
 **Timing:** median of N=5 runs after 1 warmup, wall-clock incl. network fetch  
 **Chrome:** `/Applications/Google Chrome.app/Contents/MacOS/Google Chrome`  
@@ -11,16 +11,16 @@
 <!-- BEGIN RESULTS TABLE -->
 | URL | SSIM | pixdiff % | webengine ms | chrome ms | speed× | region | status |
 |-----|-----:|----------:|-------------:|----------:|-------:|:------:|:------:|
-| example.com/ | 0.954 | 1.5 | 50.2 | 2109.5 | 42.03 | 1024×768 | ok |
-| en.wikipedia.org/wiki/Go_(programming_language) | 0.434 | 22.1 | 2808.1 | 4395.9 | 1.57 | 1024×2500 | ok |
-| pkg.go.dev/net/http | 0.644 | 33.7 | 5105.1 | 4117.8 | 0.81 | 1024×2500 | ok |
-| go.dev/blog/ | 0.684 | 19.0 | 4122.4 | 3007.6 | 0.73 | 1024×1597 | ok |
-| react.dev/ | 0.613 | 46.4 | 1790.8 | 2550.9 | 1.42 | 1024×2500 | ok |
-| news.ycombinator.com/ | 0.606 | 13.9 | 1323.1 | 2588.5 | 1.96 | 1024×1109 | ok |
-| developer.mozilla.org/en-US/docs/Web/CSS | 0.609 | 18.4 | 415.3 | 2114.8 | 5.09 | 1009×2500 | ok |
-| github.com/golang/go | 0.543 | 30.2 | 3067.3 | 2305.9 | 0.75 | 1024×2500 | ok |
-| tailwindcss.com/ | 0.704 | 13.3 | 3106.5 | 2447.4 | 0.79 | 1024×2500 | ok |
-| caniuse.com/ | 0.664 | 18.0 | 3585.0 | 3824.3 | 1.07 | 1024×1737 | ok |
+| example.com/ | 0.954 | 1.5 | 90.1 | 1956.3 | 21.72 | 1024×768 | ok |
+| en.wikipedia.org/wiki/Go_(programming_language) | 0.423 | 22.6 | 3560.5 | 4405.5 | 1.24 | 1024×2500 | ok |
+| pkg.go.dev/net/http | 0.644 | 33.7 | 6202.0 | 4410.7 | 0.71 | 1024×2500 | ok |
+| go.dev/blog/ | 0.684 | 19.0 | 4654.2 | 2947.5 | 0.63 | 1024×1597 | ok |
+| react.dev/ | 0.613 | 46.4 | 2242.8 | 2733.6 | 1.22 | 1024×2500 | ok |
+| news.ycombinator.com/ | 0.643 | 12.7 | 1611.6 | 2672.1 | 1.66 | 1024×1109 | ok |
+| developer.mozilla.org/en-US/docs/Web/CSS | 0.633 | 14.1 | 609.9 | 2131.0 | 3.49 | 1009×2500 | ok |
+| github.com/golang/go | 0.543 | 30.2 | 3025.6 | 2360.5 | 0.78 | 1024×2500 | ok |
+| tailwindcss.com/ | 0.708 | 12.8 | 3944.3 | 2586.4 | 0.66 | 1024×2500 | ok |
+| caniuse.com/ | 0.664 | 18.1 | 3718.4 | 4036.4 | 1.09 | 1024×1737 | ok |
 <!-- END RESULTS TABLE -->
 
 Speed× is `chrome_ms / webengine_ms`: >1 means webengine is faster.
@@ -69,6 +69,10 @@ Speed× is `chrome_ms / webengine_ms`: >1 means webengine is faster.
 
 <!-- BEGIN ANALYSIS (hand-written, preserved across re-runs) -->
 
+## Honest analysis — 2026-09-09 (round 71): two real, independently-confirmed gaps in dynamic script loading closed (missing `onload`/`onerror`; a script appended during timer-draining could be silently stranded) — neither alone closes react.dev's own `ChunkLoadError`, whose remaining cause is flagged as a separate, deeper issue (engine#160)
+
+**react.dev: SSIM 0.6126→0.6126, exactly unchanged — correctly predicted in advance, not a surprise**: direct instrumentation confirms the chunk-loader's own dynamically-created `<script src="…f809.js">` is still never fetched, even after both fixes. Traced precisely: `document.createElement('script')` and `document.head.appendChild(...)` both run correctly with the right `src`, but two real, separate defects were gating anything further — (1) `onload`/`onerror` did not exist as properties on any element at all, so even a successful chunk load could never have resolved webpack's own loading promise, and (2) `Session.RunPending` decided whether "anything happened" from `runScripts` alone, called BEFORE `drainTimers` — but the standard chunk-loading idiom creates its `<script>` from exactly a timer callback, so a freshly-appended, never-executed script could sit in the DOM while the caller's settle loop read a false "ran" as "nothing left to do" and stopped iterating, never picking it up. Fixed by wiring `onload`/`onerror` generically (backed by a new per-node handler-slot map so a later assignment correctly replaces, not stacks with, an earlier one) and by having `RunPending` check for pending unexecuted scripts after draining timers. An initial version of the second fix over-corrected — running `runScripts` twice within one `RunPending` call broke `TestSettleFixpointCap` by advancing a synchronous self-replicating script chain two generations in one outer pass instead of one — fixed by reporting "pending" without executing inline, preserving the existing per-pass pacing. Even combined, these fixes don't close the visible symptom: the most likely remaining cause is that this engine's `setTimeout` binding ignores its own delay argument, draining every timer job in pure FIFO order — so a bundler's internal "give up after 120s" safety-net timeout structurally races ahead of (and always wins against) the chunk's own near-instant real fetch. That's a genuinely deeper, separate architectural simplification, not attempted this round. Other corpus movements (en.wikipedia.org, developer.mozilla.org, news.ycombinator.com, tailwindcss.com) are consistent with this harness's own already-documented noise sources — external banner/ad-slot toggling for the first two, HN's own live rotating front page for the third (checked directly: identical stories/ranking, no attributable difference) — none plausibly related to this round's script-loading-specific fixes.
+
 ## Honest analysis — 2026-09-09 (round 70): `document.currentScript` was hardcoded to always return null, so a bundler's own base-URL detection came back empty for every chunk load — found live on tailwindcss.com's Turbopack runtime via a fresh `Engine.JSLog` sweep (engine#159)
 
 **tailwindcss.com: SSIM 0.7053→0.7038, ordinary noise, correctly not reported as a visual win** — the 10 Turbopack chunks that now load successfully (previously all failing with "chunk path empty but not in a worker") are plausibly deferred/lazy UI enhancements outside the top-of-page region this comparison captures; a direct render of the real page looks the same at a glance, before and after. The bug: `document.currentScript` was unconditionally hardcoded to `null`, so the standard Webpack/Turbopack idiom of reading `document.currentScript.src` to compute a chunk-loading base path always got an empty result outside a Worker. Fixed by actually tracking the synchronously-executing `<script>` node (`binder.currentScript`, set immediately before and cleared immediately after each `execute()` call in the one call site that invokes it) rather than special-casing the property — matching the real spec exactly, including going back to null inside a later timer callback. A pre-existing test (`TestDocumentMisc`) had encoded the old always-null behaviour as its own expectation; updated to check `instanceof HTMLScriptElement` instead, which is both correct and more informative than relying on incidental string output. The real, demonstrated value here is JavaScript execution correctness — ten fewer failed script runs on a real production site's actual bundle — not a fidelity number. Two other pages (en.wikipedia.org, developer.mozilla.org) landed back on their exact round-68 baseline SSIM values this run, reconfirming the already-documented external-content-variability pattern (Wikipedia's intermittent promotional banner, MDN's own third-party ad slot) rather than anything this fix touches.
diff --git a/bench/out/caniuse.com.png b/bench/out/caniuse.com.png
index e86e861..a4a639d 100644
Binary files a/bench/out/caniuse.com.png and b/bench/out/caniuse.com.png differ
diff --git a/bench/out/developer.mozilla.org_en-US_docs_Web_CSS.png b/bench/out/developer.mozilla.org_en-US_docs_Web_CSS.png
index 91cb8c2..7fc406b 100644
Binary files a/bench/out/developer.mozilla.org_en-US_docs_Web_CSS.png and b/bench/out/developer.mozilla.org_en-US_docs_Web_CSS.png differ
diff --git a/bench/out/en.wikipedia.org_wiki_Go_programming_language.png b/bench/out/en.wikipedia.org_wiki_Go_programming_language.png
index 960ca98..6acc7ba 100644
Binary files a/bench/out/en.wikipedia.org_wiki_Go_programming_language.png and b/bench/out/en.wikipedia.org_wiki_Go_programming_language.png differ
diff --git a/bench/out/github.com_golang_go.png b/bench/out/github.com_golang_go.png
index 5f4ce2a..0edded3 100644
Binary files a/bench/out/github.com_golang_go.png and b/bench/out/github.com_golang_go.png differ
diff --git a/bench/out/news.ycombinator.com.png b/bench/out/news.ycombinator.com.png
index 8b00b03..23d4dd0 100644
Binary files a/bench/out/news.ycombinator.com.png and b/bench/out/news.ycombinator.com.png differ
diff --git a/bench/out/react.dev.png b/bench/out/react.dev.png
index e45a887..a8e474a 100644
Binary files a/bench/out/react.dev.png and b/bench/out/react.dev.png differ
diff --git a/bench/out/tailwindcss.com.png b/bench/out/tailwindcss.com.png
index b2d20fd..bb7c33d 100644
Binary files a/bench/out/tailwindcss.com.png and b/bench/out/tailwindcss.com.png differ
diff --git a/bench/results.json b/bench/results.json
index 3022b65..144379d 100644
--- a/bench/results.json
+++ b/bench/results.json
@@ -1,9 +1,9 @@
 [
   {
     "url": "https://example.com/",
-    "webengine_ms": 50.19,
-    "chrome_ms": 2109.522,
-    "speed_ratio": 42.03072325164376,
+    "webengine_ms": 90.076,
+    "chrome_ms": 1956.303,
+    "speed_ratio": 21.71836005151206,
     "ssim": 0.9541451179596087,
     "pixdiff_pct": 1.53350830078125,
     "region_w": 1024,
@@ -14,11 +14,11 @@
   },
   {
     "url": "https://en.wikipedia.org/wiki/Go_(programming_language)",
-    "webengine_ms": 2808.129,
-    "chrome_ms": 4395.877,
-    "speed_ratio": 1.5654113468433966,
-    "ssim": 0.43376860237167725,
-    "pixdiff_pct": 22.061171875,
+    "webengine_ms": 3560.529,
+    "chrome_ms": 4405.463,
+    "speed_ratio": 1.2373057486682455,
+    "ssim": 0.42289887244503654,
+    "pixdiff_pct": 22.6463671875,
     "region_w": 1024,
     "region_h": 2500,
     "montage": "out/en.wikipedia.org_wiki_Go_programming_language.png",
@@ -27,9 +27,9 @@
   },
   {
     "url": "https://pkg.go.dev/net/http",
-    "webengine_ms": 5105.13,
-    "chrome_ms": 4117.752,
-    "speed_ratio": 0.8065910172708629,
+    "webengine_ms": 6201.999,
+    "chrome_ms": 4410.695,
+    "speed_ratio": 0.7111731233752214,
     "ssim": 0.6435426619444631,
     "pixdiff_pct": 33.6956640625,
     "region_w": 1024,
@@ -40,9 +40,9 @@
   },
   {
     "url": "https://go.dev/blog/",
-    "webengine_ms": 4122.412,
-    "chrome_ms": 3007.557,
-    "speed_ratio": 0.7295624503324751,
+    "webengine_ms": 4654.22,
+    "chrome_ms": 2947.526,
+    "speed_ratio": 0.6333018207132451,
     "ssim": 0.6835407066166453,
     "pixdiff_pct": 19.02700864902943,
     "region_w": 1024,
@@ -53,10 +53,10 @@
   },
   {
     "url": "https://react.dev/",
-    "webengine_ms": 1790.845,
-    "chrome_ms": 2550.925,
-    "speed_ratio": 1.424425341109923,
-    "ssim": 0.612591251167784,
+    "webengine_ms": 2242.775,
+    "chrome_ms": 2733.637,
+    "speed_ratio": 1.2188636844979992,
+    "ssim": 0.612597132081433,
     "pixdiff_pct": 46.423398437500005,
     "region_w": 1024,
     "region_h": 2500,
@@ -66,11 +66,11 @@
   },
   {
     "url": "https://news.ycombinator.com/",
-    "webengine_ms": 1323.059,
-    "chrome_ms": 2588.474,
-    "speed_ratio": 1.9564312702608124,
-    "ssim": 0.606299034173214,
-    "pixdiff_pct": 13.94828885820559,
+    "webengine_ms": 1611.572,
+    "chrome_ms": 2672.134,
+    "speed_ratio": 1.6580916024850272,
+    "ssim": 0.6431851090845011,
+    "pixdiff_pct": 12.71635834648332,
     "region_w": 1024,
     "region_h": 1109,
     "montage": "out/news.ycombinator.com.png",
@@ -79,11 +79,11 @@
   },
   {
     "url": "https://developer.mozilla.org/en-US/docs/Web/CSS",
-    "webengine_ms": 415.276,
-    "chrome_ms": 2114.756,
-    "speed_ratio": 5.092410830387501,
-    "ssim": 0.60875508648779,
-    "pixdiff_pct": 18.369236868186324,
+    "webengine_ms": 609.945,
+    "chrome_ms": 2131.039,
+    "speed_ratio": 3.4938215740763514,
+    "ssim": 0.6330293140259217,
+    "pixdiff_pct": 14.128642220019822,
     "region_w": 1009,
     "region_h": 2500,
     "montage": "out/developer.mozilla.org_en-US_docs_Web_CSS.png",
@@ -92,11 +92,11 @@
   },
   {
     "url": "https://github.com/golang/go",
-    "webengine_ms": 3067.251,
-    "chrome_ms": 2305.858,
-    "speed_ratio": 0.7517669730974087,
-    "ssim": 0.543321694376328,
-    "pixdiff_pct": 30.1932421875,
+    "webengine_ms": 3025.55,
+    "chrome_ms": 2360.518,
+    "speed_ratio": 0.7801946753482838,
+    "ssim": 0.5434039906712012,
+    "pixdiff_pct": 30.1891796875,
     "region_w": 1024,
     "region_h": 2500,
     "montage": "out/github.com_golang_go.png",
@@ -105,11 +105,11 @@
   },
   {
     "url": "https://tailwindcss.com/",
-    "webengine_ms": 3106.514,
-    "chrome_ms": 2447.395,
-    "speed_ratio": 0.7878268052228318,
-    "ssim": 0.703834739996964,
-    "pixdiff_pct": 13.2530078125,
+    "webengine_ms": 3944.334,
+    "chrome_ms": 2586.437,
+    "speed_ratio": 0.6557347831091384,
+    "ssim": 0.70823820369105,
+    "pixdiff_pct": 12.791015624999998,
     "region_w": 1024,
     "region_h": 2500,
     "montage": "out/tailwindcss.com.png",
@@ -118,11 +118,11 @@
   },
   {
     "url": "https://caniuse.com/",
-    "webengine_ms": 3584.989,
-    "chrome_ms": 3824.333,
-    "speed_ratio": 1.066762826887335,
-    "ssim": 0.6642873287595739,
-    "pixdiff_pct": 18.029525133131834,
+    "webengine_ms": 3718.367,
+    "chrome_ms": 4036.445,
+    "speed_ratio": 1.0855423899792571,
+    "ssim": 0.6641586604080089,
+    "pixdiff_pct": 18.097215475676453,
     "region_w": 1024,
     "region_h": 1737,
     "montage": "out/caniuse.com.png",
diff --git a/js/dom.go b/js/dom.go
index bc2d170..d7072d7 100644
--- a/js/dom.go
+++ b/js/dom.go
@@ -262,6 +262,21 @@ func (b *binder) defineElement(o *goja.Object, n *dom.Node) {
 		b.dispatch(n, eventType(call.Argument(0)), call.Argument(0))
 		return b.vm.ToValue(true)
 	})
+	// onload/onerror: the "el.onload = fn" idiom, as common as
+	// addEventListener for these two specifically — webpack's own classic
+	// chunk-loading helper (__webpack_require__.l) sets both directly as
+	// properties on a dynamically-created <script>, never via
+	// addEventListener. Confirmed load-bearing live on react.dev: with
+	// neither this property wiring NOR a dispatched load/error event (see
+	// runScripts), a code-split chunk's own onload/onerror never fired at
+	// all, so webpack's chunk-loading promise never settled and eventually
+	// reported "ChunkLoadError: ... failed" via ITS OWN timeout fallback.
+	b.accessor(o, "onload",
+		func() goja.Value { return orUndefined(b.onHandler(n, "load")) },
+		func(v goja.Value) { b.setOnHandler(n, "load", v) })
+	b.accessor(o, "onerror",
+		func() goja.Value { return orUndefined(b.onHandler(n, "error")) },
+		func(v goja.Value) { b.setOnHandler(n, "error", v) })
 
 	// Layout/geometry: backed by the real laid-out box tree when a Metrics source
 	// is installed (the engine's settle loop), else zeros (the legacy no-layout
diff --git a/js/dynamic_test.go b/js/dynamic_test.go
index 6fde849..2165ed6 100644
--- a/js/dynamic_test.go
+++ b/js/dynamic_test.go
@@ -8,6 +8,8 @@ import (
 	"testing"
 	"time"
 
+	"github.com/dop251/goja"
+
 	"github.com/go-webengine/engine/dom"
 )
 
@@ -127,6 +129,102 @@ func TestSessionRunPending(t *testing.T) {
 	}
 }
 
+// TestSessionInjectedScriptOnloadAndOnerrorFire covers the standard webpack/
+// Turbopack chunk-loading idiom directly: document.createElement('script');
+// s.onload=fn; s.src=...; parent.appendChild(s) — for both outcomes (the
+// script fetches and runs; the fetch fails). Before this, no element had an
+// onload/onerror PROPERTY at all (a plain, silently-ignored assignment), and
+// runScripts never dispatched "load"/"error" on a <script> after handling
+// it, so neither outcome was ever observable to the page's own code — a
+// dynamic loader's promise could never settle either way.
+func TestSessionInjectedScriptOnloadAndOnerrorFire(t *testing.T) {
+	src := `<html><head></head><body><script>
+		var ok=document.createElement('script');
+		ok.onload=function(){ console.log('ok-onload'); };
+		ok.onerror=function(){ console.log('ok-onerror (should not fire)'); };
+		ok.textContent='console.log("ok-ran");';
+		document.body.appendChild(ok);
+
+		var bad=document.createElement('script');
+		bad.onload=function(){ console.log('bad-onload (should not fire)'); };
+		bad.onerror=function(){ console.log('bad-onerror'); };
+		bad.src='https://demo.test/does-not-exist.js';
+		document.body.appendChild(bad);
+	</script></body></html>`
+	root, err := dom.Parse(src)
+	if err != nil {
+		t.Fatal(err)
+	}
+	var logs []string
+	sess := Begin(root, Options{PageURL: "https://demo.test/", Timeout: 3 * time.Second,
+		Log: func(l string) { logs = append(logs, l) }})
+	defer sess.Close()
+	sess.RunInitial()
+	sess.RunPending()
+	mustHaveJS(t, logs, "ok-ran", "ok-onload", "bad-onerror")
+	joined := strings.Join(logs, "\n")
+	if strings.Contains(joined, "should not fire") {
+		t.Fatalf("a handler fired for the wrong outcome: %v", logs)
+	}
+}
+
+// TestSessionRunPendingReportsPendingScriptAppendedDuringDrainTimers covers a
+// narrower case than TestSessionRunPending above: a <script> that appears in
+// the DOM not because THIS call's own runScripts found and ran a script that
+// appended it, but because a timer job — already sitting in the queue from
+// an earlier phase, exactly like webpack/Turbopack's own chunk-loading
+// "give up after N ms" fallback surviving to fire later — is what drainTimers
+// fires DURING this same RunPending call. Before this was fixed, RunPending
+// decided its "ran" return value from runScripts alone, BEFORE drainTimers
+// (called right after) had a chance to inject anything — so a script
+// appended this way sat in the DOM, correctly never re-executed, but
+// invisible to the caller: dynamic.go's settle loop reads a false "ran" as
+// "nothing left to do" and stops iterating, so this <script> was NEVER RUN
+// AT ALL. Confirmed live on react.dev's own webpack chunk-loading bundle via
+// direct instrumentation (see FIDELITY.md): a dynamically-created
+// <script src="…f809.js"> was correctly appended to <head> with the right
+// src, but its fetch was never even attempted.
+func TestSessionRunPendingReportsPendingScriptAppendedDuringDrainTimers(t *testing.T) {
+	root, err := dom.Parse(`<html><head></head><body></body></html>`)
+	if err != nil {
+		t.Fatal(err)
+	}
+	var logs []string
+	sess := Begin(root, Options{PageURL: "https://demo.test/", Timeout: 3 * time.Second,
+		Log: func(l string) { logs = append(logs, l) }})
+	defer sess.Close()
+	sess.RunInitial()
+
+	// Simulate a timer job that only fires NOW, as part of THIS RunPending's
+	// own drainTimers step, by enqueuing it directly rather than via a
+	// script runScripts would itself discover and run first (which would
+	// set "ran" true from that alone, never exercising the bug).
+	fnVal, err := sess.b.vm.RunString(`(function(){
+		var s = document.createElement('script');
+		s.textContent = 'window.__v=(window.__v||0)+1; console.log("inj v="+window.__v);';
+		document.body.appendChild(s);
+	})`)
+	if err != nil {
+		t.Fatal(err)
+	}
+	fn, ok := goja.AssertFunction(fnVal)
+	if !ok {
+		t.Fatal("expected a callable function value")
+	}
+	sess.b.jobs = append(sess.b.jobs, timerJob{fn: fn})
+
+	if !sess.RunPending() {
+		t.Fatal("RunPending should report true: drainTimers just appended a script that is now waiting to run")
+	}
+	// The appended script is deliberately NOT run inline within the same
+	// call (see RunPending's own doc comment on why, and
+	// TestSettleFixpointCap for what breaks if it were) — a follow-up call,
+	// matching how dynamic.go's settle loop actually behaves on ran==true,
+	// is what runs it.
+	sess.RunPending()
+	mustHaveJS(t, logs, "inj v=1")
+}
+
 // TestMarkJSEnabled covers the exported pre-cascade signal helper.
 func TestMarkJSEnabled(t *testing.T) {
 	MarkJSEnabled(nil) // no panic
diff --git a/js/events.go b/js/events.go
index fbb6311..cd48375 100644
--- a/js/events.go
+++ b/js/events.go
@@ -28,6 +28,41 @@ func (b *binder) addListener(n *dom.Node, typ string, handler goja.Value) {
 	b.listeners[n][typ] = append(b.listeners[n][typ], handler)
 }
 
+// setOnHandler implements an "onX" IDL event-handler-attribute assignment
+// (`el.onload = fn`): removes whatever handler this exact (n, typ) slot
+// previously held (a real browser lets a later assignment replace, not
+// stack, unlike addEventListener), then registers the new one the same way
+// addEventListener would — dispatch needs no separate code path for onX
+// handlers versus addEventListener ones. A non-function value (including
+// null/undefined, the standard way script clears a handler) only removes.
+func (b *binder) setOnHandler(n *dom.Node, typ string, v goja.Value) {
+	if m := b.onHandlers[n]; m != nil {
+		if old, ok := m[typ]; ok {
+			b.removeListener(n, typ, old)
+			delete(m, typ)
+		}
+	}
+	if v == nil || goja.IsUndefined(v) || goja.IsNull(v) {
+		return
+	}
+	if _, ok := goja.AssertFunction(v); !ok {
+		return
+	}
+	b.addListener(n, typ, v)
+	if b.onHandlers[n] == nil {
+		b.onHandlers[n] = map[string]goja.Value{}
+	}
+	b.onHandlers[n][typ] = v
+}
+
+// onHandler returns the current onX handler for (n, typ), or nil.
+func (b *binder) onHandler(n *dom.Node, typ string) goja.Value {
+	if m := b.onHandlers[n]; m != nil {
+		return m[typ]
+	}
+	return nil
+}
+
 // removeListener unregisters a previously added handler.
 func (b *binder) removeListener(n *dom.Node, typ string, handler goja.Value) {
 	m := b.listeners[n]
diff --git a/js/js.go b/js/js.go
index 14634ee..1b79dde 100644
--- a/js/js.go
+++ b/js/js.go
@@ -88,6 +88,13 @@ type binder struct {
 	windowNode *dom.Node // sentinel node keying window-level listeners
 	docNode    *dom.Node // sentinel node keying document-level listeners
 	listeners  map[*dom.Node]map[string][]goja.Value
+	// onHandlers tracks the current "onX" IDL event-handler-attribute value per
+	// (node, type) — e.g. `el.onload = fn` — as ONE slot that a later
+	// assignment replaces, unlike addEventListener's list. Implemented as a
+	// registered listener under the hood (see setOnHandler) so dispatch needs
+	// no separate code path; this map exists only so a reassignment can find
+	// and remove the PREVIOUS handler before adding the new one.
+	onHandlers map[*dom.Node]map[string]goja.Value
 
 	jobs     []timerJob
 	nextID   int64
@@ -143,11 +150,22 @@ func (b *binder) runScripts(res *Result) {
 		b.executed[s.node] = true
 		src, ok := b.scriptSource(s)
 		if !ok {
+			// A real browser fires "error" on the <script> element itself when
+			// fetching its src fails (404, network error, …), distinct from a
+			// runtime exception during execution (which still fires "load" on
+			// the element — see below — reporting the exception separately via
+			// window's own error event instead). Dynamically-injected script
+			// loaders (webpack/Turbopack's own chunk-loading helper, confirmed
+			// load-bearing live on react.dev) set onerror/onload on the element
+			// specifically to detect this outcome; without it, a failed fetch
+			// left their loading promise pending forever.
+			b.dispatch(s.node, "error", b.newEvent("error"))
 			continue
 		}
 		b.currentScript = s.node
 		ok = b.execute(src, s.name)
 		b.currentScript = nil
+		b.dispatch(s.node, "load", b.newEvent("load"))
 		if ok {
 			res.ScriptsRun++
 		} else {
@@ -276,6 +294,18 @@ func collectScripts(root *dom.Node) []script {
 	return out
 }
 
+// hasPendingScripts reports whether the tree now holds a <script> element that
+// runScripts has not executed yet — see RunPending's own doc comment for why
+// this is checked without actually running anything here.
+func (b *binder) hasPendingScripts() bool {
+	for _, s := range collectScripts(b.root) {
+		if !b.executed[s.node] {
+			return true
+		}
+	}
+	return false
+}
+
 // scriptIsJS reports whether a <script>'s type is (classic) JavaScript. Module,
 // JSON and other typed scripts are skipped.
 func scriptIsJS(n *dom.Node) bool {
diff --git a/js/session.go b/js/session.go
index 8212289..e00a76f 100644
--- a/js/session.go
+++ b/js/session.go
@@ -71,6 +71,7 @@ func Begin(root *dom.Node, opt Options) *Session {
 		windowNode: &dom.Node{Type: dom.Element, Tag: "#window"},
 		docNode:    root,
 		listeners:  map[*dom.Node]map[string][]goja.Value{},
+		onHandlers: map[*dom.Node]map[string]goja.Value{},
 		storage:    map[string]*storageArea{},
 		executed:   map[*dom.Node]bool{},
 		deadman:    time.Now().Add(opt.Timeout),
@@ -164,7 +165,26 @@ func (s *Session) RunInitial() {
 
 // RunPending executes any <script> elements inserted into the DOM since the last
 // run (the core of a ResourceLoader-style dynamic loader) in document order,
-// then drains the async loop. It reports whether at least one new script ran.
+// then drains the async loop. It reports whether at least one new script ran
+// OR is now waiting to run — the latter matters because a callback drained
+// just now (a timer, a promise) can itself inject a brand-new <script> (the
+// standard webpack/Turbopack chunk-loading idiom: document.createElement
+// ('script'); s.onload=...; s.src=chunkURL; document.head.appendChild(s)),
+// which this call's own runScripts, having already run, never sees. Before
+// this, such a script sat newly-appended in the DOM but ScriptsRun+
+// ScriptsFailed hadn't moved, so "ran" reported false and the caller's
+// settle loop (dynamic.go) broke immediately instead of ever iterating again
+// to give it a chance — confirmed live on react.dev: instrumentation showed
+// the chunk-loader's own dynamically-created <script src="…f809.js"> WAS
+// correctly created and appended to <head> with the right src, but its
+// fetch was NEVER even attempted, because the settle loop had already
+// stopped. Deliberately NOT executed inline here (an earlier version of
+// this fix called runScripts a second time within this same call, which
+// over-eagerly ran a whole SYNCHRONOUS self-replicating script chain in one
+// pass instead of one generation per outer settle iteration, breaking
+// TestSettleFixpointCap's bounded-passes guarantee) — reporting "pending"
+// keeps the existing one-generation-per-pass pacing: the NEXT call to
+// RunPending (from the next outer iteration) is what actually runs it.
 func (s *Session) RunPending() (ran bool) {
 	s.guard(func() {
 		before := s.res.ScriptsRun + s.res.ScriptsFailed
@@ -173,6 +193,9 @@ func (s *Session) RunPending() (ran bool) {
 			ran = true
 		}
 		s.b.drainTimers(&s.res)
+		if !ran && s.b.hasPendingScripts() {
+			ran = true
+		}
 	})
 	return ran
 }