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

[2026-09-10] eagle: work/projects/cpm-web-extension-breakage-findings.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-09-10 11:15:08 +06:00
parent a6034a956c
commit 9d1a4213c6
1 changed files with 2 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
work/projects/cpm-web-extension-breakage-findings.md
+2
View File
@@ -1212,6 +1212,8 @@ Symptom match: all tabs, new tabs too, survives reload, banners not handled, das
`log stream --level debug --predicate '(subsystem == "com.apple.WebKit" AND category == "ServiceWorker") OR category == "Extensions" OR composedMessage CONTAINS "[CPM"'` `log stream --level debug --predicate '(subsystem == "com.apple.WebKit" AND category == "ServiceWorker") OR category == "Extensions" OR composedMessage CONTAINS "[CPM"'`
and look for "creating a new service worker process" followed by "Created service worker N in process PID <≠ webProcessPID of the view>" and "Job N failed with error Script error." and look for "creating a new service worker process" followed by "Created service worker N in process PID <≠ webProcessPID of the view>" and "Job N failed with error Script error."
**Why the 30 s unload does not guarantee recovery.** The stray process S is dropped only by `SWServer::removeContextConnectionIfPossible(domain)` (`SWServer.cpp:1623-1645`), which runs from `terminateServiceWorkersTimer` when the origin's **last client** unregisters (`SWServer.cpp:1546-1578`; delay 0 s if the client's registration was cleared, else 10 s). It bails out with `ShouldDelayRemoval::No` **without removing anything** if `m_clientsByRegistrableDomain` contains the domain again — i.e. if a new background view (a new client of `webkit-extension://<uuid>`) already exists when the timer fires. So recovery needs *two* quiet windows back to back: 30 s without CPM messages (failed view unloads → its client leaves) **plus** 0–10 s more without any message (otherwise the next wake creates a new client before the timer, S survives, the new worker lands in S again, `Script error.`, another 30 s). With several open tabs, auto-refreshing pages or a user who keeps browsing, that gap never comes → indefinite outage until Fire. The first manual run recovered "after a minute" only because Alex stopped touching the browser. Additionally `removeContextConnection` itself re-creates a connection (→ a new S) whenever a client is still registered at that instant (the 10:58:37.78 "creating a new service worker process" right after the failed view's deallocation); the exact trigger there needs the `[ServiceWorker]` lines preceding 10:58:37.779.
**WebKit bugs to report (two independent defects, either fix breaks the chain):** **WebKit bugs to report (two independent defects, either fix breaks the chain):**
- `NetworkConnectionToWebProcess::didClose` removes the context connection before unregistering the dead process's SW clients, so `removeContextConnection` re-creates a connection for an origin whose only client is dead. Swapping the order (or having `removeContextConnection` ignore clients belonging to the closing connection) removes the trigger. - `NetworkConnectionToWebProcess::didClose` removes the context connection before unregistering the dead process's SW clients, so `removeContextConnection` re-creates a connection for an origin whose only client is dead. Swapping the order (or having `removeContextConnection` ignore clients belonging to the closing connection) removes the trigger.
- `establishRemoteWorkerContextConnectionToNetworkProcess` falls back to a standalone worker process for a request that carries a `serviceWorkerPageIdentifier`; a SW-page worker can never work outside the page's process, so the request should be dropped when that process is gone. Additionally `tryInstallContextData` prefers an existing domain connection over the SW page's process. - `establishRemoteWorkerContextConnectionToNetworkProcess` falls back to a standalone worker process for a request that carries a `serviceWorkerPageIdentifier`; a SW-page worker can never work outside the page's process, so the request should be dropped when that process is gone. Additionally `tryInstallContextData` prefers an existing domain connection over the SW page's process.