git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-10-30] eagle: work/projects/cpm-extension-js-review-2026-10-30.md

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-10-30 19:38:23 +06:00
1 parent 71a206da13
commit 5f0cedc194
1 file changed
+14
Download Patch File Download Diff File Expand all files Collapse all files
work/projects/cpm-extension-js-review-2026-10-30.md
+14
View File
@@ -71,3 +71,17 @@ Source: [Shipped config-unavailable branch](/Users/admin/DuckDuckGo/apple-browse
Результаты: `extension-flow-probe-results.json`, `extension-flow-checkout-results.json` в `/Users/admin/DuckDuckGo/apple-browsers.git/cpm-ios-idle-wake-investigation-2026-10-30/`.
Приоритет для узкого extension fix: document-bound init/response и cancellation; затем bounded recovery исходного init после временной config ошибки. Параллельно измерить state queue, чтобы проверить её вклад в wake dashboard failures. Ни один из механизмов пока нельзя объявить единственной причиной всей production idle-wake группы.
## Длительная поломка во всех вкладках — уточнение
Общий pending remoteConfigJson способен без собственного дедлайна остановить init всех новых документов текущего worker. Контролируемая проверка shipped методов с удерживаемым config promise: три новые вкладки — 0 initResp и 0 dashboard; отдельный свежий экземпляр с доступным config работает, пока старый остаётся заблокирован. После освобождения старого promise завершаются все три init. Это доказательство зависимости/liveness при заданном stall, а не естественного WebKit trigger.
Pending state write отличается: он блокирует общий dashboard pipeline, но initResp могут продолжать отправляться. Его нельзя автоматически называть фактическим отказом CPM на страницах.
Оба дефекта per-document из предыдущих разделов способны оставлять конкретный документ без корректной инициализации до reload. Они сами по себе не доказывают поломку всех будущих документов.
Проверен shipped M4 путь: reloadExtension успешно выгружает старый context и вызывает loader.loadWebExtension; makeContext создаёт новый WKWebExtensionContext. Чистая in-memory JS очередь/promise не должны пережить действительную замену worker. В проверенном upstream WebKit context unload вызывает invalidateStorage и сбрасывает sessionStorageStore; обычный idle unload background view этого не делает. Эти детали upstream не являются верификацией каждого shipped iOS engine.
Поэтому для отказа свежих navigation после успешно выполненного M4 нужны либо повторение trigger в новом worker, либо общий нижележащий сбой, либо ошибка самого recovery/измерения. Подтверждённого чисто extension-JS состояния, которое навсегда ломает новые документы и гарантированно переживает успешную полную замену контекста, в этом проходе не найдено. session storage здесь не следует путать с постоянной дисковой записью поломки.
Артефакты: global-config-probe.cjs / global-config-probe-results.json. Проверка не запускала реальный M4 на iPhone; fresh-instance control проверяет границу JS состояния.