From 82abdf86fe39b01cc5080a1f1590238063a427fb Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 27 Oct 2026 16:39:16 +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 | 11 +++++++++++ 1 file changed, 11 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 b9548883..bf51935f 100644 --- a/work/projects/cpm-post-release-analysis-2026-10-27.md +++ b/work/projects/cpm-post-release-analysis-2026-10-27.md @@ -175,3 +175,14 @@ New `CPMReproBrokenWorkerTests` and harness changes (uncommitted): - **H2 (listener metadata loss) not confirmed:** one start without a listener only loses that navigation; P1's wake plus re-registration heals it. - **The fast-mode per-tab breakage is an artifact:** after a confirmed hang and recovery, tabs with an unanswered init kept receiving the dashboard refresh but never `initResp`. That is WebKit's silent `tabs.sendMessage` path (`processes.isEmpty()` → `{}`), and the monitor sent one `was_stuck=true / reload_state=loaded / other_tab_response` episode and nothing more. It **did not reproduce with the 30 s delay**. The TestWebKitAPI identity or the 3 s unload changes WebKit behavior; fast-mode hits must always be confirmed with the production delay. The blind spot it exposed is still real in principle: the monitor cannot see a tab that gets the dashboard refresh but no `initResp`. - **H3 (stale failed background) reproduced with production timing:** after the throwing start, error 6 is recorded and the failed background view **stays present**. The next navigation 9 s later got nothing, and only the M4 reload (new context) restored messaging. No `background_load_retry` pixel fired, so the P2 retry never completed, as predicted by WebKit's `loadBackgroundWebViewIfNeeded` early return. Cost: at least one extra lost navigation per error 6, plus a full M4 reload. On iOS, error 6 is 7.5% of episodes and 25% of stuck. + +### Production-gap ideas and coexistence screen (27 Oct) + +The harness differs from macOS production in four ways: +1. **Other extensions:** 83% of macOS 1.213 installs run the ad-blocking extension (`m.mac.web.extension.daily.ad.blocking.state.daily` `is_enabled=true` 3,486 of 4,182). It is a module service worker with DNR and four `document_start` all-frames content scripts. iOS has none; Dark Reader runs on ~140 iOS installs. +2. **Real pages:** network loads, iframes, redirects, `replaceState`. +3. **Real app tabs and windows:** visibility, App Nap, multiple windows and pinned tabs; app-hosted harness only, in a VM. +4. **Long-lived data store** with abandoned registrations; weak, since ~30 harness runs already shared one persistent store. + +- **Coexistence screen:** `CPMReproCoexistenceTests` (new `Options.embeddedTypes`), CPM + ad-blocking, fast unload, 1,000 cycles: **0 lost of 1,500 wake navigations** (85 min); at 30 s, 0 of 15. The ad-blocking background started once and unloaded at 30 s, but never woke again on fixture pages, so concurrent wakes of both backgrounds were not exercised. Its content scripts ran on every page. A second extension's content scripts alone do not trigger the wake hang. +- **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.