From 11013fffc45a0beb4ef3fe02c46f8d93bd8c046a Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 27 Oct 2026 20:17:50 +0600 Subject: [PATCH] [2026-10-27] eagle: work/projects/cpm-post-release-analysis-2026-10-27.md --- .../cpm-post-release-analysis-2026-10-27.md | 15 +++++++++++++++ 1 file changed, 15 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 f48a3b8e..60d526d6 100644 --- a/work/projects/cpm-post-release-analysis-2026-10-27.md +++ b/work/projects/cpm-post-release-analysis-2026-10-27.md @@ -197,3 +197,18 @@ The harness differs from macOS production in four ways: `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. - **600,000 entries, released origin:** first `initResp` **32.2 s** after the reload, **5 navigations lost**; still linear (~53 µs/entry). Page loads during the migration were also slower (one took 9 s), so the migration may delay browsing generally, not only CPM. A full 5-minute silence would need ~5–6M entries by extrapolation, so this explains post-reload silences of seconds to about a minute, not the whole deadline. The same blackout hits **every app launch** on released builds. With P3, 0.1 s at every size. + +### What survives the hang reload — code search and tests (27 Oct) + +Telemetry: every confirmed permanent hang (iOS 0.30%, macOS 2.07% of DAU) had the M4 reload run and stay silent, so the broken state survives a full context replacement or the trigger repeats. Checked: +- **Native messaging** (`WebExtensionMessageRouter`, `AutoconsentWebExtensionMessageHandler`): handlers keyed by extension identifier and re-registered on reload; each request is stateless. Not persistent. +- **Monitor reload bookkeeping:** responses from measurements begun on the new generation count; harness reload scenarios closed their episodes. No bug found. +- **WebKit process reuse:** `WebProcessCache` requires `usesWebProcessCache`, default false, and the app sets no process-pool options. Ruled out. +- **`storage.session` stall:** CPM's `refreshRemoteConfig` awaits `getFromSessionStorage("config")` with no timeout, so a stall would hang every `init`. No stall in any screen log; only `tabs.sendMessage` on the busy-page profile. Not reproduced. +- **Network replaced while the background is unloaded** (`testNetworkProcessReplacedWhileBackgroundIsUnloadedKeepsWakesWorking`, 30 s timing): 0 lost in 6 busy navigations and 4 idle wakes. +- **macOS tab URL:** `Tab.url(for:)` returns `content.urlForWebView`, which follows `webView.url` one main-queue hop later; WebKit reads it live for `sender.tab.url`. Harness mode `CPM_REPRO_MACOS_TAB_URL=1` reproduces the lag: 133 real-page visits, 0 lost, **0 monitor episodes**. `init` arrives after the hop. +- **`webExtensionPageWebView`:** only set for `webkit-extension:` pages and cleared on content change. Not relevant. + +**Reinterpretation:** "idle wake" is a *state at failure*, not proven to be a cause. On desktop the background unloads after every 30 s idle, so a large share of all navigations, healthy ones included, run right after a wake, and failures from any cause land in this group at that base rate. That fits P1 changing nothing. Confirming it needs a healthy-navigation baseline (background state on successful measurements); none exists since #7384 was closed. + +Remaining untested production ingredients: the real macOS `Tab` stack (DDG user scripts / content-blocking rule lists in tabs, multiple windows, pinned and hidden tabs, App Nap); needs the app-hosted harness in a VM.