From ba3a6e7a191638b502b4a5c1a6e40e4df8176e91 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 27 Oct 2026 18:26:00 +0600 Subject: [PATCH] [2026-10-27] eagle: work/projects/cpm-post-release-analysis-2026-10-27.md --- work/projects/cpm-post-release-analysis-2026-10-27.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/work/projects/cpm-post-release-analysis-2026-10-27.md b/work/projects/cpm-post-release-analysis-2026-10-27.md index c4e37567..8834bace 100644 --- a/work/projects/cpm-post-release-analysis-2026-10-27.md +++ b/work/projects/cpm-post-release-analysis-2026-10-27.md @@ -188,3 +188,11 @@ The harness differs from macOS production in four ways: - **App Store vs DMG** (macOS 1.213, 26–27 Oct, per loaded install): episodes 20.8% vs 29.7%, wake cohort 9.8% vs 10.6%, cross-tab no-response 1.2% vs 2.4%. Sandboxing does not drive the wake cohort; the DMG excess is likely early-updater bias. - **Real-page screen** (`CPMReproRealPageTests`): earlier repro tests used `loadSimulatedRequest`, so loads never reached WebKit's Network process. `CPMReproFixtureServer` serves loopback pages through it: cross-origin iframes (`localhost` vs `127.0.0.1`), 302 redirects, `replaceState`, slow images, main-thread blocks. CPM + ad-blocking, fast unload, 1,000 cycles: **0 lost of 1,333 visits** across 7 profiles (~190 each), and no monitor episodes. Real loads, frames, redirects and URL rewrites do not trigger the wake hang. - **Next hypothesis — origin-changing M4 reload stalls on large data:** most confirmed macOS cross-tab hangs (1.213, 26–27 Oct, `tabs_affected≠1` and no response) have tail `proxy_on>dealloc>view>proxy_on`, view 4–8 s, ready <1 s, scripts present, **`reload_state=loaded` (97+22+22) or `response_timed_out` (34+17+13)**. The reload loaded, yet nothing answered for the rest of the episode. Released builds load the reloaded context under a new random origin, and P3 saw WebKit's origin migration slow with a large cache. Test: `CPMReproReloadOriginTests` fills the persistent HTTP cache (`/fill`, default 20,000 × 2 KB) and runs the M4 reload with released vs stable origin, timing post-reload silence. If confirmed, P3 also fixes hang persistence. +- **Reproduced: origin-changing M4 reload blacks out CPM proportionally to the HTTP cache** (`CPMReproReloadOriginTests`, production timing, CPM only). Fill the persistent cache through real fetches, run the hang reload (`reloadExtension(…, trigger: .cpmMessagingHang)`), navigate every 2 s: + +| Cache entries (2 KB) | Released origin (new random origin per load) | P3 stable origin | +|---|---|---| +| 20,000 | first `initResp` 1.5 s after reload, 0 lost | 0.1 s | +| 200,000 | **10.9 s, 1 lost** | 0.1 s | + +`reloadExtension` itself returns in ~20 ms; the delay is WebKit migrating extension data to the new origin before content scripts run. Roughly linear, ~50 µs per cache entry. Cookie seeding on 5,000 `.test` domains did not create website data records (still 2), so per-site record cost is untested. The same migration runs on every **app launch** in released builds, which links this to the P3 startup cohort. **P3 (#7493) removes it in both cases.** It explains `reload_state=response_timed_out` and extended post-reload silence; whether real caches are large enough for a full 5-minute silence is being checked at 600,000 entries.