obsidian-vault/work/projects/cpm-web-extension-repro-and-fix-2026-10-08.md

title, date, status, tags, updated

title	date	status	tags	updated
CPM Web Extension — воспроизведение и фикс	2026-10-08	historical-investigation	work cpm webkit	2026-10-20

CPM Web Extension — воспроизведение и фикс

Актуализировано 20 октября 2026. Этот документ сохраняет последовательность исследования и старый A/B/phase-1 design 8–9 октября. «Ничего не закоммичено», общая ready-handshake branch и line/test counts ниже относятся к своим датам.

Текущие implementations: #7379 P1/P2/P4; #7459 Network recovery с applied daily+count; #7493 ограниченный stable-origin P3 policy; #7473 shared-pinned window close merged 20 октября в release/macos/1.213.0 (9bcce0264e); rollout не подтверждён. Heads, bases и CI — cpm-status-2026-10-15#2. PR и quality gates, worktrees — cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа.

#7376 уже переработан в один terminal episode report: four-state stuck, двухфазный bounded bg_events, daily+count. Он закрыт без merge; macOS counterpart отстаёт. Полный контракт — cpm-pr0-episode-telemetry-summary-2026-10-16. Final pending-load outcome, page ACK и network attribution episode пока отсутствуют; весь production Others эти данные не объясняют.

Исторический контекст — 15 октября 2026

Текущий статус — 15 октября 2026: cpm-status-2026-10-15. Актуальная карта файлов и worktree — cpm-web-extension-code-guide-2026-10-09 (§0). «Ничего не закоммичено», общий ready-handshake worktree и counts ниже относятся к состоянию 8–9 октября; A/B/telemetry уже разделены на PR, их актуальные heads/CI проверены в основном статусе.

Новое продолжение в alex/cpm-web-extension-remaining-failures: 14 P5/P6 методов с green по отдельным логам, включая shared-window callback → system WebKit → P5/tab=false и условный main-flag handler cycle → P6. Факт flag-transition у пользователей и естественный вход P5/tab=true/listener metadata неизвестны. Контроли не дали P5 при длинных документах, одном missing-listener wake или host main-actor stall. Embedded-only first-init loss относится к A; после explicit ready wait controller остаётся correct.

Последний обычный пакет этого worktree: 478 XCTest, 28 skipped, 0 failures; 14 slow repro выполнялись отдельно. Цифры 490/677/761 в других branches описывают иные тестовые базы, не этот прогон. Все исходные красные эксперименты и ограничения сохранены в основном статусе §10–12; этот отчёт ниже сохранён как историческая цепочка расследования.

Продолжение cpm-web-extension-breakage-session-summary-2026-10-07 (§8 «План точного воспроизведения»). Среда: macOS 26.7.1 (25G241), system WebKit, production embedded extension 2026.9.29. Код: worktree alex/cpm-web-extension-ready-handshake, пакет SharedPackages/WebExtensions. Ничего не закоммичено.

Статус (9 октября)

Карта кода по строкам: cpm-web-extension-code-guide-2026-10-09. Сводки на английском: cpm-web-extension-data-analysis-summary-2026-10-08, cpm-web-extension-repro-and-fixes-summary-2026-10-08. Ничего не закоммичено.

• Фиксы — worktree alex/cpm-web-extension-ready-handshake: gate первой загрузки посреди сессии, watchdog Network-процесса, перезапуск по первому сбою. Тесты зелёные (490 в пакете на момент фикса).
• Расследование без фиксов — worktree alex/cpm-web-extension-remaining-failures: error 6 (причина в WebKit, репро на macOS), задержка очистки при смене baseURL (репро на macOS), медленный старт worker'а на пробуждении — сигнатура группы 1 воспроизведена.
• Телеметрия фазы 1 — worktree alex/cpm-messaging-readiness-telemetry от свежего main: готовность background, возраст view, состояние приложения, вкладки, error 6, детали восстановления. 677 тестов, SwiftLint, валидатор пикселей, сборка iOS и macOS — зелёные.
• Эксперимент — ветка alex/cpm-stable-base-url: стабильный baseURL (на старой базе, не прогнан через harness).
• Не воспроизведены: привязка вкладок на macOS, «нет background view», код 7, первый сбой после M4; error 6 на iPhone.

Что нашли

Отказ одной вкладки — потеря init при первой загрузке background

• WebKit при первой загрузке extension с новым идентификатором (первая установка или обновление — апгрейд ставит новый UUID) грузит background сразу. runtime.sendMessage, пришедший до выполнения background-скрипта, резолвится undefined, listener не вызывается.
• Без gate: 14/20 при первой установке, 18/20 при обновлении; с busy-wait 1 с в скрипте — 3/3 детерминированно.
• При обычном перезапуске (extension уже установлен), после reload (M4) и при пробуждении после idle WebKit ставит сообщения в очередь — потерь нет.
• Поправка к первому отчёту: при запуске это уже закрывает gate в WebExtensionLifecycleCoordinator (флаг webExtensionStateRestorationGate). Дыры были: установка или обновление посреди сессии (sync(), отложенная установка на iOS до protected data), таймаут gate 5 с.

Полный отказ — мёртвый worker при живом background

• Краш Network-процесса (SIGKILL, аналог jetsam на iOS): background view и его PID прежние, WebKit считает background загруженным, worker мёртв. Теряются сообщения из всех вкладок и уже открытых документов. Монитор: init failed → stuck → M4. После M4 новые навигации работают, документы, открытые до сбоя, сломаны навсегда. Без M4 держится, пока пользователь активен; снимается после ~30 с idle-выгрузки. 20/20.
• Смерть worker'а при живом Network-процессе: _terminateServiceWorkers (SPI) или удаление service worker registrations из data store (то, что делает очистка данных). Состояние то же.
• Fire в обоих приложениях выгружает extensions на время очистки и загружает потом, поэтому сам Fire сюда не приводит. Других путей в проде, которые убивают только worker, не нашёл.
• Не триггеры: org.WebKit.lowMemory, заморозка background на 10–75 с, kill background-процесса (WebKit перезапускает сам).
• Если background занят или заморожен дольше ~30 с, WebKit выгружает его, и сообщение «в полёте» теряется навсегда (одна вкладка, не каскад).

Восстановление

• Убить только background WebContent-процесс (_killWebContentProcessAndResetState) — WebKit поднимет новый worker на следующем сообщении; новые навигации и уже открытые документы работают.
• Reload extension (M4) чинит только новые навигации.
• loadBackgroundContent() ничего не даёт: WebKit считает background загруженным.

Почему мёртвый worker не обнаружить из приложения

• Регистрация SW остаётся activated.
• runtime.sendMessage из page world background web view до worker'а не доходит (WebKit считает страницу самим background-контекстом) — и у живого, и у мёртвого worker'а сразу undefined.
• Background CPM слушает только onMessage, onConnect (порт privacy-dashboard) и onAlarm — приложение не может их вызвать.

Фикс (app, пакет WebExtensions)

1. Gate для первой загрузки посреди сессии. После installEmbeddedExtension менеджер запоминает задачу loadBackgroundContent() нового контекста; coordinator.initialLoadWaiter (его уже вызывают обе платформы на каждой main-frame навигации) после открытия стартового gate отдаёт этот waiter, не дольше 5 с.
2. EmbeddedBackgroundLivenessWatchdog. Запоминает PID Network-процесса background'а; при смене перезапускает background-процесс. Проверка на каждой навигации и раз в 1 с.
3. Перезапуск по первому сбою. Монитор вызывает onEpisodeStarted на первом сбое обычной навигации; менеджер перезапускает background, если процесс отвечает (callAsyncJavaScript("return 1"), 1 с). Замороженный или занятый не трогаем: убийство остановленного процесса давало глухой новый worker.
4. Пункты 2 и 3 включаются одним переключателем isEmbeddedBackgroundRecoveryEnabled (по умолчанию true).

Сценарий	Без фикса	С фиксом
Установка посреди сессии	3/3 потерь	5/5 доставлено
Обновление посреди сессии	5/5 потерь	5/5 доставлено
Краш Network-процесса, 4 вкладки + открытые документы	все сломаны	всё работает
Краш Network-процесса без M4	не восстанавливается	работает
Смерть worker'а (SPI / удаление регистраций)	2 таймаута → M4, старые документы сломаны	1 потерянная навигация, затем всё работает без reload

Фиксы ↔ гипотезы

Фикс	Гипотеза	Подтверждена данными?
Gate на первую загрузку посреди сессии	Потеря init при eager-загрузке background нового идентификатора (317981), не про Network-процесс	Нет. Косвенно — app_version_change=updated, но запуск и так под gate; частота установок посреди сессии неизвестна
Watchdog по PID Network-процесса	Краш Network-процесса → мёртвый worker при «живом» background	Частично (см. ниже)
Перезапуск по первому сбою	Мёртвый worker по любой причине при отзывчивом процессе background'а	Не проверена: из app причину не видно

Сверка с собранными данными (5 октября)

Источник: apple-browsers.git/cpm-public-attribution-2026-10-06/events.tsv (строки stuck .count) и events_daily.tsv (в скобках). Группы по приоритету, как в атрибуции.

Группа по снимку	iOS: всего / network_restarted=true	macOS: всего / network_restarted=true
Вкладка: controller/scripts/tab	81 / 10% (13%)	102 / 1% (2%)
Нет background view	158 / 11% (14%)	35 / 3% (3%)
Error 6 (background не загрузился)	579 / 10% (14%)	3 / –
died_* (процесс background умер)	14 / 86% (85%)	0
Снимок без видимой ошибки	1 410 / 17% (21%)	705 / 30% (45%)

За гипотезу о Network-процессе: смена Network-процесса заметно чаще в группе «без видимой ошибки» — там, где её предсказывает механизм. В остальных группах ~10% на iOS и 1–3% на macOS. Смерть процесса background'а почти всегда вместе со сменой Network-процесса — похоже на jetsam на iOS, убивающий оба.

Почему это не доказательство: network_restarted сравнивает PID с загрузкой контекста, а не с последним созданием background view. В почти всех таких строках последние события — view, proxy_on за 30 с – 5 мин до снимка. Если view пересоздан после смены процесса, worker свежий и механизм не применим. Порядок из текущих данных не восстановить.

Итог: механизм объясняет в лучшем случае 20–45% «здоровых» stuck. Остальное — другие дефекты, которые текущими фиксами не покрыты:

• Error 6 — ~1/3 всех строк iOS. WebKit сам сообщает, что background не загрузился (dealloc → error:6 → view…). Worker не поднимается, а не тихо умирает. Перезапуск по сбою почти не поможет: после error 6 view обычно нет. Отдельный приоритет для iOS.
• Вкладка не привязана (macOS: неверный controller и нет scripts; iOS: нет scripts) — привязка вкладки к контексту, фиксы не трогают.
• Нет background view — WebKit не пересоздал background; обоим механизмам нужен живой view.
• «Здоровые» без смены Network-процесса — крупнейший необъяснённый остаток (1 170 iOS / 497 macOS). Кандидаты: другая смерть worker'а (поймает перезапуск по сбою), поздний или несопоставленный refreshCpmDashboardState при живом worker'е (перезапуск — ложное срабатывание), первая загрузка вне gate. Без native_seen не разделить.

Непокрытые группы: расследование (8 октября)

Worktree alex/cpm-web-extension-remaining-failures, ветка от того же коммита a0717cf098, без фиксов — чтобы воспроизводить на коде как в проде. Фиксы остаются незакоммиченными в alex/cpm-web-extension-ready-handshake.

• В harness перенесена инфраструктура (без watchdog/recovery) и подключён production CPMMessagingDiagnosticsRecorder: воспроизведённые сбои дают те же параметры пикселей, что и прод (bg_events, context_errors, network_restarted, …). Watcher логирует context.errors.
• Новый набор CPMReproBackgroundLoadFailureTests: idle-выгрузка (~32 с), затем пробуждение навигацией при заданном условии.

Error 6 (BackgroundContentFailedToLoad, ~1/3 строк stuck на iOS)

WebKit (WebExtensionContextCocoa.mm): error 6 ставится, когда _loadServiceWorker вернул success=false (:2796) или упала навигация background-страницы (:3052). Код 7 — внутренний ScriptExecutionError (didEncounterScriptError, :284): JS-ошибка в скрипте extension во время работы. В проде: 7,6 — 283, только 6 — 259, 6,7 — 103 из 645 строк iOS с error 6.

Условие при пробуждении (macOS)	Результат
Без помех	доставлено
Network-процесс заморожен 5/10/60 с	пробуждение потеряно, error 6 нет, потом всё работает
Network-процесс убит перед пробуждением	доставлено
Background убит во время загрузки	пробуждение потеряно (died_client), error 6 нет
Файлы extension отсутствуют	error 6 + WKWebExtensionErrorDomain:2 — в проде кода 2 нет, не причина
Background-скрипт бросает на верхнем уровне / нет browser/chrome	error 6 без кода 7 — точная продовая сигнатура «только 6», но продовой причины падения скрипта не нашлось
Новый процесс background заморожен ≥30 с во время загрузки	таймаут загрузки SW → background none + error 6, цепочка view, proxy_on, unresponsive, error:6, dealloc; 10 с — error 6 нет; после разморозки работает

Причина в коде WebKit (подтверждено): WebExtensionContext::wakeUpBackgroundContentIfNecessary (WebExtensionContext.cpp) первым делом вызывает scheduleBackgroundContentToUnload() — взводит 30-секундный idle-таймер выгрузки до того, как service worker загрузился. Если загрузка не закончилась за 30 с, таймер вызывает unloadBackgroundContentIfPossible → unloadBackgroundWebView() → view закрывается посреди загрузки → колбэк _loadServiceWorker(success=false) → error 6. Это объясняет продовый порядок dealloc → error:6 → view и репро с заморозкой: 45 с → error 6, 10 с → нет.

Тест-репро на macOS (Tests/WebExtensionsTests/CPMRepro/CPMReproBackgroundLoadFailureTests.swift, worktree alex/cpm-web-extension-remaining-failures), с проверками, все 9 зелёные:

cd SharedPackages/WebExtensions && CPM_REPRO=1 swift test --filter CPMReproBackgroundLoadFailureTests

• testBackgroundStalledPastUnloadTimerFailsToLoad — новый процесс background заморожен на 45 с при пробуждении → context_errors = только :6, bg_load_error_after=25s_to_35s, bg_load_error_app_state=active, следующее пробуждение работает.
• testBackgroundStalledLessThanUnloadTimerLoads — 10 с → error 6 нет.
• testMissingExtensionFilesFailWithAFileError, testThrowingWorkerScriptFailsToLoad, testWorkerWithoutExtensionBindingsFailsToLoad — error 6 через under_5s (отличаются от таймера по новому параметру).
• testWakeWithoutInterferenceLoads, testFrozenNetworkProcessDoesNotFailTheLoad, testNetworkProcessCrashBeforeWakeDoesNotFailTheLoad, testBackgroundKilledDuringLoadDoesNotFailTheLoad — error 6 нет.

iOS Simulator: тесты пакета непоказательны — процесс xctest не получает RunningBoard assertions, background не работает с начала. Приложение DDG в симуляторе работает, но фоновое приложение не приостанавливается. Видно, что CPM сам будит background будильником cpm-summary (через 2 мин после активности), в том числе когда приложение в фоне.

iPhone 12 mini, iOS 26.7.1, debug-сборка DDG (установлена поверх 7.221.0) — error 6 не воспроизвёлся:

Сценарий	Результат
Свернуть на 2,5 мин при стоящем будильнике	приложение приостановлено целиком, будильник срабатывает при возврате, загрузка ~0,1 с
Разбудить и сразу свернуть (4 задержки)	загрузка успевает за ~0,1 с
Звук играет в фоне, будильник будит background в фоне	background создаётся и грузится, через 30 с штатно выгружается
Фоновый запуск системой (--no-activate)	не проверено: консоль не подключается, log collect требует sudo

Вывод: на ненагруженном устройстве загрузка всегда укладывается в 30 с. Оставшиеся кандидаты: нехватка памяти / jetsam на нагруженных устройствах; фоновый запуск системой (fetch/processing), когда приложение приостанавливают посреди загрузки, а при возврате просроченный таймер срабатывает раньше её завершения. Решено не подбирать условия вслепую, а добавить телеметрию (ниже).

Телеметрия для error 6 — реализована (не закоммичено, worktree alex/cpm-web-extension-remaining-failures):

• Новые параметры у всех 8 CPM-пикселей с диагностикой на iOS и macOS (debug_web_extension_cpm_initialization_failed_after_*, debug_web_extension_cpm_messaging_stuck_*):
  • bg_load_error_app_state — состояние приложения, когда контекст последний раз записал error 6: none / active / inactive / background;
  • bg_load_error_after — время от создания view, чья загрузка упала, до error 6: none / under_5s / 5s_to_25s / 25s_to_35s / over_35s. 25s_to_35s — idle-таймер WebKit.
• Код: CPMAppSessionDiagnostics получил провайдер applicationState (iOS — UIApplication.applicationState, macOS — NSApp.isActive); CPMMessagingDiagnosticsRecorder фиксирует состояние и задержку в момент записи error 6, сбрасывает при новом контексте; CPMMessagingDiagnostics отдаёт параметры (none, если ошибки не было; опускает, если неизвестно).
• JSON5: params_dictionary.json5 и определения (iOS debug_pixels.json5, macOS web_extensions.json5); validate-pixel-defs проходит на обеих платформах.
• Тесты: 2 unit-теста в CPMMessagingDiagnosticsTests.swift (захват состояния и задержки, бакеты) + сквозная проверка в тесте-репро. Весь пакет: 459 тестов, 0 падений. SwiftLint чистый.
• Ожидаемое чтение данных: 25s_to_35s + background → загрузка, застрявшая из-за фона; 25s_to_35s + active → медленная загрузка на переднем плане (память, нагрузка); under_5s → сломанный скрипт или файлы.

Возможный фикс после данных: при возврате приложения на передний план, если context.errors содержит error 6, — перезапустить background; либо не будить background, пока приложение в фоне (изменение extension или WebKit).

Группа 1 («здоровый» снимок без смены Network-процесса) — разбор 8 октября

Данные (events_daily.tsv, stuck): iOS 748, macOS 228.

• Самый частый хвост bg_events — dealloc → view → proxy_on, последний view моложе 30 с до снимка: iOS 219 (+154 при 1m), macOS 120 из 228. Сбой совпадает с пробуждением background после idle-выгрузки.
• Около четверти iOS (и ~15% macOS) — после загрузки контекста: хвосты load → view / base_url_changed → view, reason=extension.reload (iOS 71, macOS 39).
• macOS: app_version_change=updated у 144 из 228 (63%; в среднем по stuck — 52%).
• context_errors=none у 675/748 iOS; память (critical_memory_age) почти везде none.
• Ответ часто опаздывает, а не теряется — поправка 8 октября: recovered_without_extension_reload(initialization_failed) к stuck не относится. Он закрывает только эпизод, который ещё не stuck: пришёл опоздавший ответ на упавшее измерение или следующая навигация в той же вкладке ответила. Stuck-эпизод сразу уходит в M4, и его восстановление считается как recovered_after_extension_reload(messaging_stuck); без reload из stuck — 0 строк.
  • У recovery-пикселей только appVersion и cpm_recovery_from: хвостов, задержки и признака «тот же документ / следующая навигация» нет.
  • initialization_failed — только .daily (на причину), recovery — daily+count. Сравнимо только daily/daily за 5 октября: iOS 1 555 / 6 624 = 23% (33% от after_other), macOS 353 / 1 405 = 25% (33% от after_other). count/daily recovery ≈ 1,9 на устройство-день на iOS — у одних и тех же устройств повторяется.
  • Stuck → recovered after M4 (daily): iOS 916 / 1 440 = 64%, macOS 362 / 489 = 74%.
  • Хвосты «здоровых» init-сбоев vs stuck (iOS): load/base_url_changed → view — ~32% init против ~18% stuck; dealloc → view (пробуждение) — ~44% init против ~61% stuck (macOS: ~36% → 52% только @30s). То есть сбои после загрузки контекста чаще проходят сами (согласуется с задержкой чистки при смене baseURL), а пробуждение чаще доходит до stuck.
  • Нужно в телеметрию: на recovery-пиксель — задержку ответа от начала измерения (бакеты 4–8 с / 8–30 с / >30 с), same_document vs next_navigation и хвост bg_events на момент сбоя.
• Версии ОС: на macOS «здоровые» сбои есть и на 26.7, и на 27.0 (92 и 178 init в срезе сравнения ОС). Версии iOS в выгрузке нет — нужен запрос в ClickHouse.

WebKit-баги (bugs.webkit.org, компонент WebKit Extensions, изменения с мая 2026):

• 320812 / 312231@main — медленная чистка при загрузке контекста (главная находка). Начиная с 26.6, WebExtensionContext::load() при смене baseURL переименовывает localStorage/IndexedDB и удаляет все website data предыдущего origin, включая DiskCache (обход всего сетевого кэша на главном потоке Network-процесса). m_safeToInjectContent, addInjectedContent() и загрузка background ждут окончания этой чистки. У DDG baseURL новый при каждом запуске и каждом M4 reload. Код есть и в 7624.5.1.11.3 (macOS 26.7.1), и в 7625.1.29 (27.0). Фикс 318756@main (7 авг) попал в ветку safari-7625 (316606.407@safari-7625-branch); в какую сборку ОС — не проверено.
• 324743 (fixed 22 сен, нет в 26.7/27.0) — worker считается загруженным до завершения регистрации. Зона «пробуждение после idle»; наши тесты пробуждения на Mac проходят, детерминированного репро нет.
• 322881 (fixed 31 авг) — worker теряет clients после выгрузки и перезагрузки; CPM clients не использует.
• 314194 (открыт) — в Lockdown Mode блокируются все service worker'ы, включая background extension → CPM никогда не работает. Доля пользователей DDG с Lockdown Mode неизвестна; сигнатура в наших данных не определена.
• 319976 (fixed) — loadBackgroundContentWithCompletionHandler вызывал completion дважды при ошибке; мы используем этот API в gate.

Репро медленной чистки на Mac (CPMReproExtensionLoadCleanupTests.swift, нужен локальный сервер CPM_REPRO_CACHE_URL с /fill.html?n=N): кэш тестового процесса наполнен ~24 тыс. записями (у реального DDG на этом Mac — 18,7 тыс., 877 МБ).

	Пустой кэш	~24 тыс. записей
Перезапуск: content script выполнился на мс документа	23	770–1 350
Перезапуск: background создан через	0,2 с	0,9–1,5 с
Reload (как M4): content script на мс документа	—	780–790

На быстром Mac задержка меньше 4 с монитора, поэтому сбоя нет. На iPhone с большим кэшем и медленным CPU нужно мерить (на тестовом iPhone кэш маленький: «Context will load» → «Background web view created» за 30–70 мс).

Проверено и отброшено:

• Блокировка устройства: у iOS-приложения нет entitlement'а default-data-protection → класс CompleteUntilFirstUserAuthentication; файлы доступны при блокировке после первой разблокировки. Исключение — запуск до первой разблокировки, для него есть protectedDataLoadGate.
• Устаревший URL вкладки на iOS (addressBarURLFilter не обновляет URL при межоригинном переходе со страницы): в didCommit url = webView.url выставляется синхронно до init → для обычной навигации ответ приходит с верным URL.

Медленный старт worker'а на пробуждении — сигнатура группы 1 воспроизведена (8 октября, эксперимент, не закоммичено). Тест CPMReproWakeExperimentTests в обоих worktree: после idle-выгрузки в начало background-скрипта на диске добавляется busy-wait (только на этот wake), через 1 с скрипт восстанавливается.

• busy 0,3 / 1 / 2,5 с и задержка activate 1–3 с: сообщения ставятся в очередь и доставляются, задержка ответа = время старта. Потерь нет.
• busy 5 с: initialization_failed_after_other с bg_process_responsive=true, context_errors=none, хвост dealloc/view/proxy_on@30s — как в проде. Ответ приходит через ~1 с после сбоя → recovered_without_extension_reload(initialization_failed).
• busy 12 с + следующая навигация после сбоя: второй сбой → messaging_stuck_other с той же сигнатурой → M4. M4 убивает медленный, но живой worker: init уже открытых документов теряется, новые навигации работают (recovered_after_extension_reload).
• С фиксами (worktree A) то же самое. Рестарт на первом сбое (onEpisodeStarted) не сработал: проба отзывчивости по 1 с истекла на занятом процессе. Если же медленный старт не загружает CPU (например, ждёт I/O), проба ответит, и рестарт убьёт worker, который ещё грузится. Это нужно закрыть.
• Чем реально вызван старт дольше 4 с на устройствах, неизвестно. Кандидаты: конкуренция за CPU с загружаемой вкладкой, запуск процесса без prewarm на iOS, низкий приоритет процесса extension (RunningBoard), занятый Network-процесс. Мерить на iPhone: от wake до первого recv init.
• Speculative fix: (1) будить background заранее — при старте навигации или при выходе приложения на передний план, без блокировки; (2) не эскалировать в M4 и не рестартовать, пока background view моложе ~15 с; (3) телеметрия: возраст background view в секундах на момент сбоя и задержка позднего ответа на recovery-пикселе; (4) опционально держать background живым, пока приложение на переднем плане (цена — память одного WebContent-процесса).

Сигналы готовности background (тест testReadinessSignalsDuringSlowWake, worker стартует 5 с):

• isLoading=false у background view через 0,11 с — бесполезен: страница загружается задолго до worker'а.
• loadBackgroundContent completion пришёл через 5,096 с, сразу после выполнения кода worker'а верхнего уровня («prelude evaluated» на 5,08 с). Это точный сигнал. Вызов сам будит выгруженный background.
• Первое нативное сообщение worker'а (getResourceIfNew) — на 5,088 с. Тоже точный сигнал, менять расширение не нужно.
• SPI для готовности нет: у WKWebExtensionContext из относящегося к background есть только _backgroundWebView, _backgroundContentURL, isLoaded (это контекст, не background) и loadBackgroundContentWithCompletionHandler:.
• В диагностике нет числа вкладок и числа загружающихся вкладок; гипотезу «много вкладок → медленный старт» проверить нечем.

Стабильный baseURL (ветка alex/cpm-stable-base-url, не закоммичено): оценка.

• Объясняет только подгруппу «после load/reload» (~¼ iOS, ~15% macOS группы 1) и, вероятно, первый сбой после M4. Основная часть (пробуждение после idle) не затронута: чистка идёт только в load().
• Изменение: context.baseURL = webkit-extension://<uniqueIdentifier>/, где uniqueIdentifier = UUID() на установку/обновление (WebExtensionManager+EmbeddedExtensions.swift:157).
• Приватность: во всех 4 встроенных манифестах нет web_accessible_resources; cpm.js не вызывает runtime.getURL; в background getURL только для tabs.create (страница расширения). Страница не может прочитать или проверить URL. Данные origin расширения и сейчас переживают перезапуск: WebKit их переносит (_renameOrigin). Риск появится, если расширение с WAR получит стабильный URL. Поэтому стабильный URL нужен только для встроенных расширений без WAR.
• Обновление: новый UUID → новый URL; старый контекст выгружается до загрузки нового — проверить. M4 reload с тем же URL: проверить, что нет BaseURLAlreadyInUse и что битая SW-регистрация не переживает reload (сценарии network-crash + watchdog).
• До принятия: прогнать harness (cleanup, M4, network crash) на ветке; телеметрия длительности load→view.

Привязка вкладок на macOS (tab_controller_match=false + нет scripts, ~100 строк)

• Гипотеза атрибуции не подтвердилась. Путь в коде есть: выключение флага webExtensions вызывает uninstallAllExtensions() и обнуляет менеджер, включение создаёт новый с новым controller, а WKWebViewConfiguration старых вкладок не меняется. Но флаг .webExtensions = remoteReleasable(WebExtensionsSubfeature.featureEnabled) с defaultValue: .enabled, а подфичи featureEnabled нет ни во встроенном, ни в текущем удалённом macos-config.json → флаг всегда enabled (отсутствующая подфича возвращает defaultValue). Мигать нечему.
• Порядок запуска не объясняет: setupWebExtensions() (AppDelegate.swift:1509) вызывается до восстановления сессии (:1526), раньше вкладки не создаются.
• tab_controller_match считается как tabController != nil && tabController === context.webExtensionController (CPMMessagingDiagnosticsRecorder.swift:378) — false и при отсутствующем controller у вкладки, и при устаревшей ссылке на контекст.
• Следующие кандидаты: вкладки из createWebViewWith (popup / target=_blank) и кэш закреплённых вкладок; пересборка user scripts в UserContentController приложения при обновлении правил content blocking — может стирать скрипты extension из вкладки (на iOS есть группа «скриптов нет при верном controller»).

Ещё не начато

• Нет background view (158 iOS / 35 macOS).
• Причина долгого старта worker'а на реальных устройствах (группа 1): мерить на iPhone от пробуждения до первого recv init при загружающейся вкладке; дождаться bg_ready_after / bg_view_age / open_tabs из прода.

Телеметрия для валидации

Выпустить раньше фиксов или вместе с ними в A/B — иначе эффект фиксов не отделить. Все значения — bool/enum/bucket, без URL и идентификаторов; оформить через ddg-add-pixel, privacy triage (прецедент — cpm-m3-telemetry-privacy-triage).

Подтвердить сбои — параметры к существующим initialization_failed / stuck:

1. network_replaced_since_view (bool) — PID Network-процесса при последнем создании background view ≠ текущему. Прямая подпись мёртвого worker'а. Recorder уже вычисляет это (CPMMessagingDiagnosticsRecorder.swift:285-289), но только логирует. Плюс токен net_replaced в bg_events, чтобы видеть порядок. Самое дешёвое и самое ценное.
2. native_seen (none / site_check / refresh_other_url) — были ли нативные вызовы от background для этой навигации (background зовёт isFeatureEnabled с URL вкладки при обработке init). Делит сбой на «не дошло до worker'а» / «worker обработал, refresh опоздал» / «рассогласование URL на native». Только app.
3. bg_first_load (bool) + токены install / upgrade / bg_loaded в bg_events — подпись бага первой загрузки.
4. gate (none / launch / startup / timeout) — прошла ли навигация мимо gate или он открылся по таймауту 5 с.

Подтвердить, что фиксы работают:

1. Пиксель debug_web_extension_cpm_background_restarted (daily+count): trigger = network_process_replaced / initialization_failed; outcome = restarted / skipped_unresponsive / spi_unavailable.
2. Атрибуция восстановления: recovery_action (none / background_restart) к recovered_without_extension_reload, либо пара recovered_after_background_restart / background_restart_failed (следующая навигация после перезапуска тоже упала → M4).
3. Ожидаемый эффект: падают messaging_stuck и M4 (recovered_after_extension_reload); почти исчезают вторые сбои эпизода с native_seen=none + network_replaced_since_view=true; исчезают сбои с bg_first_load=true вне запуска.
4. A/B, а не просто флаг: recovery и новый gate — за экспериментальным флагом (ddg-add-feature-flag), когорта в CPM-пикселях. Сравнение версий (1.208 → 1.209) уже оказалось неинформативным.

Не измерить без extension: восстановление уже открытых документов (монитор меряет только навигации) и причину смерти worker'а при живом Network-процессе.

Фаза 1 реализована — worktree alex/cpm-messaging-readiness-telemetry (от main 92e09cdbbc, 8 октября, не закоммичено)

Только телеметрия, поведение детектора не меняется.

• На initialization_failed_* и messaging_stuck_* (iOS + macOS):
  • bg_ready_after — none / pending / failed / under_1s … over_30s. Источник — completion у loadBackgroundContent. Он вызывается один раз на следующем шаге run loop после didCreateBackgroundWebView: view уже есть, поэтому вызов лишь присоединяется к идущей загрузке и ничего не будит. Отключается тем же флагом, что и delegate proxy (cpmBackgroundDelegateProxy). Код — CPMBackgroundReadinessObserver.swift.
  • bg_view_age — under_4s / 4s_to_8s / 8s_to_30s / 30s_to_2m / over_2m.
  • app_state — состояние приложения в момент сбоя.
  • open_tabs — размер context.openTabs, бакетами; loading_tabs — сколько из них в isLoading.
  • Перенесены из worktree B: bg_load_error_app_state и bg_load_error_after (error 6).
• На recovered_without/after_extension_reload:
  • recovery_document — failed_navigation (опоздавший ответ), later_navigation, unattributed;
  • recovery_after — время от первого сбоя эпизода.
• Проверено на реальном WebKit (harness, медленный старт worker'а 5 с на пробуждении): сбой ушёл с bg_ready_after=pending, bg_view_age=4s_to_8s, а восстановление — с recovery_document=failed_navigation, recovery_after=under_4s.
• Пакет: 677 тестов зелёные. SwiftLint чистый. validate-pixel-defs проходит на iOS и macOS.
• Замечание по harness: network_restarted там иногда true без падения Network-процесса; вероятная причина — тестовый процесс перезапускает Network-процесс между загрузкой контекста и сбоем (не проверено). К продовой телеметрии это не относится, но в тестах этот флаг для классификации не годится.

Тесты

Папка Tests/WebExtensionsTests/CPMRepro/, запуск из SharedPackages/WebExtensions:

• CPM_REPRO=1 swift test --filter CPMRepro — путь приложения: CPMReproSingleTabTests (10), CPMReproFullFailureTests (8). Должны быть зелёными.
• CPM_REPRO=1 CPM_REPRO_WEBKIT=1 — ещё CPMReproWebKitTests (7): защиты выключены, тесты утверждают, что баги WebKit всё ещё есть. Покраснеют, когда Apple исправит — сигнал убрать обходы.
• Ручки: CPM_REPRO_ITERATIONS, CPM_REPRO_FREEZE, CPM_REPRO_INSTALL_DIR (настоящий перезапуск процесса: запустить дважды).
• Unit-тесты без env: EmbeddedBackgroundLivenessWatchdogTests (11), 4 новых в WebExtensionLifecycleCoordinatorTests, 3 новых в CPMMessagingHealthMonitorTests.

Открытые вопросы — решить до коммита

• Feature flag. Watchdog и перезапуск по первому сбою сейчас включены по умолчанию (isEmbeddedBackgroundRecoveryEnabled = { true }), в приложениях не подключены к удалённому флагу. Завести флаг (ddg-add-feature-flag), желательно раздельно для watchdog и для перезапуска по сбою.
• Риск перезапуска по первому сбою. Первых сбоев много (~6.6k установок/день на iOS); часть — не мёртвый worker (нет инъекции, медленный native). Перезапуск дешевле M4, но рвёт незавершённую работу background для других вкладок. Решить: включать сразу или через эксперимент.
• Телеметрия. Восстановление после перезапуска сейчас попадает в recovered_without_extension_reload и неотличимо. Реализовать план из раздела «Телеметрия для валидации»; минимум — network_replaced_since_view, native_seen и пиксель background_restarted.
• Порядок выкатки. Телеметрия раньше фиксов или вместе с ними в A/B-эксперименте с когортой в CPM-пикселях.
• Error 6 на iOS (~1/3 строк stuck) не покрыт фиксами. Причина найдена в WebKit (idle-таймер 30 с взводится до окончания загрузки), репро на macOS есть. На iPhone (iOS 26.7.1) в четырёх сценариях не воспроизвёлся. Выпустить телеметрию bg_load_error_app_state / bg_load_error_after, по данным выбрать фикс. Опционально: фоновый запуск системой с sudo log collect на Mac пользователя.
• На тестовом iPhone стоит debug-сборка DDG вместо 7.221.0 — вернуть из App Store, когда тесты закончатся.
• Привязка вкладок на macOS: гипотеза мигания флага отброшена; проверить popup-вкладки, кэш закреплённых вкладок и пересборку user scripts.
• Телеметрия для error 6: состояние приложения и задержка до ошибки — реализовано в alex/cpm-web-extension-remaining-failures (не закоммичено). Нужны privacy triage и решение, в каком PR выпускать.
• Остаток «здоровых» сбоев без смены Network-процесса (группа 1): около половины — пробуждение, сигнатура воспроизведена медленным стартом worker'а; около четверти iOS — после загрузки контекста (задержка очистки при смене baseURL). Подтвердить телеметрией фазы 1.
• SPI. Перезапуск через _killWebContentProcessAndResetState, детекция через _networkProcessIdentifier; есть responds(to:). Согласовать с командой (приложение уже использует SPI WebKit в этом месте).
• Сборка приложений с фиксами. Worktree с фиксами (alex/cpm-web-extension-ready-handshake) iOS и macOS не собирал; изменения обратно совместимы. Worktree телеметрии собран на обеих платформах.
• Перезапуск по первому сбою vs медленное пробуждение. Если медленный старт не занимает CPU, проба ответит и перезапуск убьёт грузящийся worker. Не перезапускать и не эскалировать в M4, пока background не готов (bg_ready_after=pending) или view моложе ~15 с — это фаза 2 детектора.
• Фаза 2 детектора: отсчёт 4 с от готовности background; отдельный пиксель «background не стартовал за 30 с»; stuck / M4 / перезапуск только при готовом background.
• Раннее пробуждение background при начале навигации и выходе приложения на передний план (loadBackgroundContent, без блокировки).
• Стабильный baseURL: ограничить встроенными расширениями без web_accessible_resources (сейчас диф меняет URL для всех в makeContext), прогнать harness (M4, краш Network-процесса, обновление), перенести на свежий main.
• Выпуск телеметрии фазы 1: privacy triage, решить, отдельным PR или вместе с фиксами в A/B.
• Номер сборки ОС с фиксом 318756@main (очистка при смене baseURL) — не проверен.
• Zero-loss для смерти worker'а. Нужен ping-канал в extension (native port с heartbeat или обработчик ping) — задача в репозитории extension.
• Не воспроизведено: продовое «первый probe после M4 падает» (670 iOS / 232 macOS). В тестах после M4 навигации проходят.
• WebKit-баги для репорта: (1) потеря сообщения при eager-загрузке background первой загрузки; (2) после краша Network-процесса или удаления регистраций WebExtensionContext не замечает мёртвый worker.
• Прогнать на macOS 27 VM — фикс 317981 может уже стоять; тогда testWebKitDropsInitDuringFirstBackgroundLoad покраснеет.
• Отчёт cpm-web-extension-repro-results-2026-10-07.md в apple-browsers.git устарел: он не учитывает gate приложения и фиксы. Актуальное — эта заметка.