obsidian-vault/work/projects/cpm-web-extension-breakage-findings.md

title, date, status, tags

title	date	status	tags
CPM Web Extension Breakage Findings	2026-09-08	investigation	work cpm webkit web-extension

CPM Web Extension Breakage Findings

Investigation summary as of 2026-09-08. This note distinguishes confirmed code paths from hypotheses that still need production evidence.

2026-09-10: one production cause CONFIRMED — closing a window while shared pinned tabs exist makes WebKit forget those tabs (didCloseWindow → didCloseTab/forgetTab for every tab the closing window reports, and DDG reports shared pinned tabs from every window). CPM dies in the pinned tabs only; new tabs work; new window / Fire / extension reload repairs. See "✅ CONFIRMED" section near the end. Everything WebKit-internal below (retained failed view, dead worker, listener gating) remains unconfirmed on shipping WebKit.

Updated 2026-09-09 after source and shipping-WebKit validation (WebKit trunk 0c7e7ad97b, see cpm-web-extension-breakage-validation for file:line evidence). The retained-failed-view state is real but self-heals via the 30 s idle eviction. The source-level dead-worker state matches "stuck across all tabs", but neither critical memory pressure nor Network-process termination reproduced it on the tested macOS 26.x build. No permanent all-tabs production trigger is currently confirmed. removeAllUserScripts() is explicitly implemented as RemoveWebExtensions::No and does not remove CPM's WebExtension scripts.

Executive summary

The same visible symptom, CPM no longer managing consent, can come from four materially different failures:

Failure mode	Scope	Expected recovery	Confidence
CPM content script misses a document	Current document	A navigation or reload after the extension finishes loading	Confirmed
WebKit loses routing for an individual tab	Tab or WebContent process	A fresh tab/window, or rebuilding the affected tab	Confirmed historically; the known app lifecycle cause is fixed
WebKit retains a background service worker that failed to load	Extension context/controller	[corrected] Recovers by itself: the next wake-up arms the 30 s idle-eviction timer, the failed view is unloaded, and the following message retries. Persistent only if every retry fails (e.g. SW script missing on disk)	Confirmed WebKit state machine; self-healing unless the failure cause is repeatable
Background service worker terminated while WebKit still reports the background as loaded	Extension context (all tabs)	Only after ≥30 s with no extension events (idle eviction), or context unload/reload	Confirmed state shape in source; proposed memory-pressure and Network-process triggers did not reproduce it on tested shipping WebKit

The debug-menu simulation enters the third state deliberately. It proves the health detection and failure shape, but its exact trigger cannot happen naturally in the same way because only the debug delegate closes the newly created background web view in that synchronous interval.

There is currently no single strongest production hypothesis. The authoritative list below supersedes the older ranking retained later in this note as investigation history.

Current working hypotheses (authoritative, 2026-09-09)

No persistent production trigger has been reproduced yet. The remaining hypotheses are:

Hypothesis	Exact condition required	Resulting sequence	Current status
Background event starvation from page-generated traffic	One or more pages create/navigate frames or otherwise generate CPM messages faster than the shared background worker can finish them. CPM is injected into all_frames; handlers have no global concurrency limit or backpressure.	Each frame sends init -> the background starts concurrent native/config/rule work -> queued tasks and replies grow -> messages from unrelated tabs are delayed -> repeated traffic keeps the worker active and prevents the 30 s idle reset.	Concrete production input exists; no stable repro yet. Expected to recover after the producer stops and work drains, unless it pushes WebKit into another failure state.
Background JavaScript/JSC stops making progress	A synchronous non-yielding task, runaway task production, or WebKit/JSC deadlock blocks the single background event loop. An unresolved Promise alone is insufficient.	WebKit dispatches every tab's RuntimeOnMessage to the same worker -> no handler runs or replies -> all tabs miss initResp -> incoming traffic can keep the hidden background view alive.	Symptom match; no reachable infinite loop found. Current compactRuleList regexes were benchmarked and are not pathological.
WebKit says the background is loaded although its worker is gone	m_backgroundWebView != nil and m_backgroundContentIsLoaded == true, while the page has no usable serviceWorkerGlobalScope/receiving worker.	Wake-up returns success without loading a new worker -> runtime messages are dispatched toward a page with no receiver -> all tabs fail until background unload/context reload repairs the state.	Exact all-tabs state exists in source. Critical memory pressure and Network-process termination did not produce it; the production lifecycle transition is unknown.
Listener bookkeeping becomes empty or stale	RuntimeOnMessage is absent from m_backgroundContentEventListeners, or m_eventListenerFrames contains no valid receiving frame after worker unload/restart/update.	WebKit concludes there is no listener before wake-up, or finds no destination after wake-up -> messages are dropped/completed without the CPM background handler -> every tab fails.	Source-valid state; no bundle code removes the listener and no production transition into this state has been found.
Background registration/load never settles or repeatedly fails	_loadServiceWorker neither completes, or each retry fails; a pending completion/actions vector keeps the context alive. A one-off failure is insufficient because normal idle eviction recovers it.	First message starts load -> actions queue behind it -> later messages append to the queue or retry into the same failing condition -> no background handler runs for any tab.	Debug simulation proves the failure shape. A retained one-off failed view self-heals; persistent production cause unknown.
Native messaging stops producing usable replies	The background receives init, but one of getResourceIfNew, isAutoconsentSettingEnabled, or isFeatureEnabled repeatedly times out/errors, or the app-side request/router is stalled.	handleAutoConsentMessage waits -> _request returns undefined after timeout/error -> setting resolves disabled or processing aborts -> no initResp; the same shared path fails for all tabs.	Extension-side sequence confirmed. The debug no-handler switch is only a simulation; no production path that removes handlers was found. A router/request deadlock remains possible.
Downloaded CPM configuration is malformed or internally inconsistent	The running background obtains a new compactRuleList whose structure or another synchronous transform throws before tabs.sendMessage(initResp). The extension context itself is not reloaded by the privacy-config update.	Every later init reaches the same background code and fails at the same deterministic point -> no tab receives CPM initialization until valid state replaces it or the context restarts.	Low-priority data-corruption hypothesis. Current config is valid and regex performance has been ruled out; no failing historical payload is known.
Per-tab sender/response routing is stale	getTab(senderParameters.pageProxyIdentifier) fails, the frame identifier is stale, or tabs.sendMessage(initResp) targets a document/frame that no longer exists.	That document never completes initialization; another tab with valid routing continues to work.	Valid explanation for isolated tab failures, not for an extension-wide all-tabs freeze.

Explicitly not active production hypotheses: critical-memory-pressure termination (manual test negative), cold-launch/restoration miss (transient and fixed), feature-flag transitions (not a production event), privacy-config scriptlet extension reload (different extension context), removeAllUserScripts() (WebExtension scripts are excluded), and a normal page's long-running JavaScript by itself (limited to that page's WebContent thread).

CPM architecture

The bundled extension is Manifest V3:

• Background entry point: public/js/background-embedded.js
• CPM content script: public/js/content-scripts/cpm.js
• Injection: document_start, isolated world, all frames
• Content-to-background transport: chrome.runtime.sendMessage
• Background receiver: runtime.onMessage, registered by MessageRouter

The content script sends an autoconsent message to the background service worker. The background routes that message and, where required, forwards it through native messaging.

Normal message path

The relevant WebKit path is:

1. CPM content code calls chrome.runtime.sendMessage(...).
2. The WebProcess implementation enters WebExtensionAPIRuntime::sendMessage.
3. IPC sends Messages::WebExtensionContext::RuntimeSendMessage to the UIProcess.
4. WebExtensionContext::runtimeSendMessage resolves the sender with getTab(senderParameters.pageProxyIdentifier).
5. WebKit calls wakeUpBackgroundContentIfNecessaryToFireEvents(RuntimeOnMessage).
6. When the background is available, WebKit dispatches WebExtensionContextProxy::DispatchRuntimeMessageEvent.
7. The service worker's runtime.onMessage listener receives and routes the CPM message.

This gives four distinct failure boundaries:

• The content script was never injected into the document.
• The sender's page identifier no longer resolves to a registered WebExtension tab.
• WebKit decides there is no listener to wake, or cannot load the worker.
• The worker receives the message but the extension/native handler fails afterward.

Those cases should not be treated as interchangeable.

Retained failed background worker

This is the persistent WebKit state reproduced by the debug menu.

First message or initial load

The handler chain is:

1. wakeUpBackgroundContentIfNecessary
2. Append the pending operation to m_actionsToPerformAfterBackgroundContentLoads
3. loadBackgroundWebViewIfNeeded
4. loadBackgroundWebView
5. Assign m_backgroundWebView
6. Call _loadServiceWorker

The service-worker registration then follows:

1. WebPageProxy::loadServiceWorker
2. Generated page invokes navigator.serviceWorker.register(...)
3. ServiceWorkerContainer::register
4. Registration job settles
5. ServiceWorkerContainer::willSettleRegistrationPromise(success)
6. WebLocalFrameLoaderClient::didFinishServiceWorkerPageRegistration(success)
7. IPC reaches WebPageProxy::didFinishServiceWorkerPageRegistration
8. Completion returns to WebExtensionContext::loadBackgroundWebView

Failure state

When registration returns success == false, WebKit records BackgroundContentFailedToLoad and returns. In this path it does not call unloadBackgroundWebView().

The important retained state is:

• m_backgroundWebView is still non-null.
• Pending actions have not been dispatched.
• The service worker is not running.

Every later CPM message appends another pending action, calls loadBackgroundWebViewIfNeeded, and immediately returns because m_backgroundWebView already exists. The pending actions therefore never run and the worker is never replaced.

[corrected] This is not stable. wakeUpBackgroundContentIfNecessary calls scheduleBackgroundContentToUnload() before checking whether the background is loaded (WebExtensionContext.cpp:1854). The first message finds no view and arms nothing, but the second message (any tab) finds the retained view and arms the 30 s one-shot. unloadBackgroundContentIfPossible then calls unloadBackgroundWebView() (CPM holds no ports, is not inspected, has no permission prompts), the pending actions are kept, and the next message creates a fresh view and retries. The state persists only if every retry fails for the same reason.

Normal cleanup paths

These paths do clean up the background web view:

• Navigation failure: didFailNavigation records the error and calls unloadBackgroundWebView.
• WebContent process termination: webViewWebContentProcessDidTerminate calls unloadBackgroundWebView.
• Normal nonpersistent-worker eviction: unloadBackgroundContentIfPossible calls unloadBackgroundWebView.

[corrected] Ordinary idle eviction does clear the retained failed view (see above). Memory pressure and Network-process termination do not produce the retained-failed-view state, but they produce a different and worse one: they terminate the running service worker while the background view, its frame, and its listener registration remain, so WebKit keeps reporting the background as loaded (see "Ranked production trigger chains").

Debug simulation

The debug command performs this exact sequence:

1. Reload the CPM extension context.
2. WebKit creates its background web view.
3. The private delegate callback _webExtensionController:didCreateBackgroundWebView:forExtensionContext: runs synchronously after creation and before _loadServiceWorker.
4. The debug implementation removes the navigation delegate and closes the page with _close.
5. _loadServiceWorker sees a closed WebPageProxy and completes with false.
6. Because the normal navigation/process callbacks were suppressed, WebKit retains the failed m_backgroundWebView.

The following CPM message encounters the retained state. This explains why failure becomes visible one page load after activating the command.

This is a useful deterministic simulation, but not proof that production closes the page at that point.

Possible production entry

From the inspected WebKit code, _loadServiceWorker can return failure when:

• The WebPageProxy is already closed.
• A service-worker launch completion handler is unexpectedly already present.
• The actual navigator.serviceWorker.register job settles as a failure.

The first condition is manufactured by the debug command. The natural production candidate is therefore a real registration failure, potentially involving script/resource loading, service-worker registration storage, or the Network process. The source establishes that these categories can fail; it does not identify which one occurred in reported sessions.

A re-entrancy problem involving an already-present launch completion handler is also possible from the API shape, but there is currently no observed production sequence proving it.

Known transient paths

Startup and state restoration

The app initializes the WebExtension manager before state restoration, but extension synchronization and loading continue asynchronously:

1. AppDelegate.applicationDidFinishLaunching
2. setupWebExtensions()
3. Manager/controller creation
4. Async coordinator.loadAndSync()
5. stateRestorationManager.applicationDidFinishLaunching()
6. Restored tabs and web views are created with the shared controller
7. A restored document may commit before extension loading reaches addInjectedContent

The WebKit extension-load side is:

1. WebExtensionLoader.loadWebExtension
2. WKWebExtensionController.load(context)
3. WebExtensionController::load
4. WebExtensionContext::load
5. Storage migration completion
6. m_safeToInjectContent = true
7. Background loading and dispatchDidLoad
8. addInjectedContent

If the restored page has already committed, its document_start opportunity is gone. A later reload injects CPM and recovers. This explains the reproduced startup miss, but not a permanently stuck extension.

WebKit dropped-first-message bug

WebKit bug 317981 describes a first message being silently dropped when persisted listener state is empty before the background has loaded once.

Before the fix, wakeUpBackgroundContentIfNecessaryToFireEvents interpreted the empty set as “no listener” instead of “listener state not known yet,” so it did not wake or queue the message. The fix introduced m_backgroundContentHasLoadedOnce and treats the pre-first-load listener state as unknown.

This is another transient startup failure. It does not retain a failed background web view and therefore does not explain cross-navigation stuck behavior.

Scriptlet extension reload

The scriptlet update path unloads the old context and loads a newly created one. During that interval:

• Existing documents may still have old JavaScript whose extension context proxy has been removed.
• A navigation can commit before the replacement context adds its injected content.

A navigation after the new context finishes loading should recover. This becomes persistent only if the replacement service worker itself enters the retained failed-load state.

Fire

Fire unloads extension contexts, clears website data, may reopen a window, and only then reloads extensions. A reopened page can commit while there is no loaded CPM extension context and miss document_start.

Again, a later navigation should recover unless the new background-worker load fails persistently.

Application or embedded-extension update

Extension replacement previously had lifecycle windows in which an old context was removed before its replacement was ready. That known app-side lifecycle problem was fixed in 60dc9c2795 and is historical context only; this note intentionally does not preserve its detailed sequence.

Window-scope implication

DuckDuckGo attaches the same webExtensionManager.controller to tab configurations across browser windows.

Opening another window reports didOpenWindow to the controller/context and registers the new window and tabs. It does not normally reload the extension context.

Therefore, if WebKit truly retains one globally failed background view in that shared context, the failure should normally affect every window using the controller. The observation that a new window works while the original remains broken points more strongly to per-tab or per-WebContent-process routing than to the global retained-worker state.

A decisive manual discriminator is:

1. Make the original window fail.
2. Confirm CPM works in a new window.
3. Return to the original window and navigate again.
4. If only the original remains broken, inspect tab/page registration.
5. If the original also recovers, the new-window event caused some global recovery and that handler chain must be traced separately.

This implication is based on controller ownership in the app and WebKit. The exact cause of the observed window behavior is not yet proven.

Scenarios not supported by current evidence

The following ideas do not yet have a traced path into a stable stuck state:

• Multiple installed browser versions
• Sleep/wake by itself
• Memory pressure by itself [corrected] Critical system memory pressure is a traced trigger on macOS: WebProcessPool::memoryPressureStatusChangedForProcess → NetworkProcess::TerminateIdleServiceWorkers → SWServer::terminateIdleServiceWorkers kills the extension worker, which the SW server always considers idle because extension messages bypass it.
• Normal service-worker idle termination [corrected] same mechanism as above; the extension worker is idle-terminable under pressure.
• A routine WebContent-process crash (still unsupported: the background process crash path unloads the view and the next message reloads it)
• [corrected] A Network-process crash or unresponsive-kill is a traced trigger: WebProcessPool::terminateServiceWorkers() and WebProcess::networkProcessConnectionClosed → SWContextManager::stopAllServiceWorkers() stop the extension worker without touching the background view.
• Compiled content-rule cache corruption

They may alter timing or storage pressure, but should not be presented as reproduction scenarios without a corresponding failing handler sequence or production trace.

Safari 26.6 includes a fix for service-worker registration database files accumulating on launch, and WebKit has also fixed cold-launch cleanup that delayed extension content injection. [corrected] The registration-database fix is irrelevant here: extension service workers are never persisted (SWServerWorker::shouldPersistToDisk returns false for service-worker-page registrations) and the registration is cleared whenever the SW page client goes away.

Evidence needed next

The next useful instrumentation should classify the failure before attempting more scenarios:

• Inspect WKWebExtensionContext.errors for WKWebExtensionContextErrorBackgroundContentFailedToLoad.
• Invoke loadBackgroundContent(completionHandler:) diagnostically after health detection.
• A failure or completion that never arrives points to the background load/pending-action path.
• A successful background load while CPM messaging still fails points to tab/content-process routing [corrected] — or to a terminated worker under a loaded view. Discriminate by sending a probe runtime.sendMessage from a tab (or the native healthCheckRequest): undefined reply + empty errors + no Tab not found log = dead worker; tab not found error = routing.
• Capture WebKit logs around “Tab not found for message for content script message.”
• Correlate “Loading background content” with a missing “Background content loaded” and any registration error.

Without that split, repeated UI scenarios can reproduce the symptom while exercising unrelated failure modes.

Source locations

Local WebKit sparse checkout:

• Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm
• Source/WebKit/UIProcess/Extensions/WebExtensionContext.cpp
• Source/WebKit/UIProcess/WebPageProxy.cpp
• Source/WebCore/workers/service/ServiceWorkerContainer.cpp
• Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp

References:

• WebKit bug 317981: first runtime message not waking the background worker
• WebKit bug 292378: content scripts stopping after back/forward navigation
• Safari 26.6 release notes
• WebKit cold-launch extension cleanup fix

Queue and delivery failure taxonomy

The visible symptom does not by itself prove that one queue stopped. CPM messaging can fail at four different stages:

1. The WebKit background wake-up queue is entered but never drained.
2. Listener bookkeeping prevents messages from entering the wake-up queue.
3. The worker loads, but WebKit finds no process to receive the event.
4. The content-to-background message succeeds, but the background-to-tab initResp is lost.

There is also a CPM-owned JavaScript state queue. Its failure characteristics are described separately below.

Literal WebKit wake-up queue

The literal queue is m_actionsToPerformAfterBackgroundContentLoads.

It is stuck when all of the following remain true:

m_actionsToPerformAfterBackgroundContentLoads is non-empty
backgroundContentIsLoaded() is false
performTasksAfterBackgroundContentLoads() never runs
the extension context is not unloaded

Only performTasksAfterBackgroundContentLoads() executes the queued actions. Extension-context unload clears them without executing them.

The load gate never opens

m_safeToLoadBackgroundContent remains false until moveLocalStorageIfNeeded completes. When the extension base URL changed, that operation waits for the website-data store's _renameOrigin completion.

If the rename operation remains alive but never replies, loadBackgroundWebViewIfNeeded keeps returning before creating a background view. Work already queued through wakeUpBackgroundContentIfNecessary cannot run.

A normal Network-process disconnection should cancel the async IPC reply and invoke its completion. The problematic condition is an operation that remains pending without the connection being invalidated.

Service-worker launch completes with failure

WebPageProxy::loadServiceWorker can complete with false when:

• Its page is already closed.
• serviceWorkerLaunchCompletionHandler is already occupied.
• Service-worker registration is rejected.
• The worker script cannot be fetched.
• Its MIME type, scope, origin, or response is invalid.
• The worker script fails to start.
• The Network process disconnects while registration is pending.

A Network-process disconnection during registration follows this exact chain:

NetworkProcessConnection::didClose
-> WebSWClientConnection::connectionToServerLost
-> WebSWClientConnection::clear
-> SWClientConnection::clearPendingJobs
-> ServiceWorkerJob::failedWithException
-> ServiceWorkerContainer::jobFailedWithException
-> ServiceWorkerContainer::willSettleRegistrationPromise(false)
-> WebLocalFrameLoaderClient::didFinishServiceWorkerPageRegistration(false)
-> WebPageProxy::didFinishServiceWorkerPageRegistration(false)
-> _loadServiceWorker completion(false)
-> WebExtensionContext records BackgroundContentFailedToLoad
-> return without performTasksAfterBackgroundContentLoads
-> return without unloadBackgroundWebView

At that point the queued actions and background web view are both retained.

Service-worker launch never completes

The launch completion can also be lost rather than called with false:

• ServiceWorkerContainer::addRegistration rejects through an early validation branch that does not call willSettleRegistrationPromise(false). These branches cover a stopped container, Trusted Types rejection, empty or invalid URL, CSP rejection, invalid scheme, encoded slash/backslash, and invalid scope.
• startScriptFetchForJob finds no ScriptExecutionContext, notifies the server, destroys the job, and does not call willSettleRegistrationPromise.
• ServiceWorkerContainer::stop removes pending jobs without directly notifying the service-worker-page launch completion. This becomes a stall only when the associated WebPage failure/reset does not independently complete the launch.
• willSettleRegistrationPromise returns because it finds no document, no page, a page no longer marked as a service-worker page, or no local main frame.
• WebLocalFrameLoaderClient::didFinishServiceWorkerPageRegistration finds no WebPage.
• The DidFinishServiceWorkerPageRegistration IPC cannot be delivered while the UIProcess continues retaining the page.
• Origin import, registration-domain validation, script fetch, or worker startup remains pending without a process disconnection.
• SWServerJobQueue receives a callback after its registration or pre-installation worker disappeared and returns through one of its invariant-failure branches without resolving or rejecting the client job.

These paths leave serviceWorkerLaunchCompletionHandler installed and prevent performTasksAfterBackgroundContentLoads.

Messages bypass the wake-up queue

A message can be discarded before anything is queued:

• On WebKit before fix 7682d9817b, an empty persisted m_backgroundContentEventListeners set was interpreted as “no listener,” even before the background had loaded once. runtime.sendMessage completed without waking the worker.
• On current WebKit, after m_backgroundContentHasLoadedOnce == true, an absent RuntimeOnMessage entry is considered authoritative. Every later message completes without waking the worker.
• A content-script message whose pageProxyIdentifier does not resolve through getTab fails with tab not found before background wake-up.

The second condition can become extension-wide if RuntimeOnMessage was lost from the shared background-listener bookkeeping. The third condition is normally tab-local.

Worker loaded, but no receiving process

After wake-up, runtimeSendMessage obtains processes(RuntimeOnMessage, Main). The set is empty when:

• m_eventListenerFrames has no matching entry.
• Its weak listener frame has expired.
• The frame no longer has a page.
• The process cannot send messages.
• Session/private-data filtering excludes the page.
• The listener is registered under a different context proxy.

WebKit then completes the call with an empty response and does not retry.

If the set contains a process but that process remains alive and unresponsive, the async reply remains pending. IPC invalidation cancels it; an indefinitely unresponsive connection is the condition that makes it an indefinite wait.

A JavaScript listener can similarly retain the reply by returning true without calling sendResponse, or by returning a promise that never settles.

Background-to-tab init response

The CPM handshake is bidirectional:

content script: chrome.runtime.sendMessage(init)
background: chrome.tabs.sendMessage(tabId, initResp, { frameId })

The second leg does not deliver when:

• getTab(tabIdentifier) fails.
• The tab has no WKWebView.
• tab->processes(RuntimeOnMessage, ContentScript) is empty.
• The target frame identifier belongs to the previous document after navigation.
• The frame/document target no longer matches.
• The content-script listener mapping is absent from the tab's WebContent process.

The extension does not await or catch this tabs.sendMessage(initResp). Therefore the original init can finish successfully while the content script never receives configuration. This is a strong explanation for a failure confined to one tab or one WebContent process.

CPM JavaScript state queue

CPM serializes state mutations through _stateQueue:

previous _stateQueue
-> getCpmState()
-> mutation callback
-> updateCpmState()

It remains pending if:

• storage.session.get("cpmState") never settles.
• storage.session.set(...) never settles.
• A mutation callback awaits another method that calls modifyCpmState, causing a self-deadlock.
• A callback returns another permanently pending promise.

Current mutation callbacks are synchronous and do not contain the nested-await error. Native messaging is protected by a 20-second timeout.

The normal enabled init path does not await its dashboard-state update before sending initResp. A stuck _stateQueue can break diagnostics and state persistence, but does not normally explain total consent-management failure.

Exact all-tabs extension freeze sequence

The following is the exact sequence for the extension-context-wide freeze reproduced by the failed-background-load simulation. It applies to all tabs that share the same WKWebExtensionController and WKWebExtensionContext.

Entry

1. The MV3 background service worker is not currently loaded.
2. A CPM content script sends chrome.runtime.sendMessage({ messageType: "autoconsent", ... }).
3. WebProcess sends RuntimeSendMessage to WebExtensionContext::runtimeSendMessage.
4. Sender-tab lookup succeeds. This is important: a failed lookup would be a tab-local failure instead.
5. Listener gating accepts RuntimeOnMessage.
6. wakeUpBackgroundContentIfNecessary sees backgroundContentIsLoaded() == false.
7. It appends the message-dispatch closure to m_actionsToPerformAfterBackgroundContentLoads.
8. loadBackgroundWebViewIfNeeded creates m_backgroundWebView.
9. _loadServiceWorker begins registration.
10. Registration either completes with false or never completes through one of the paths listed above.
11. performTasksAfterBackgroundContentLoads is not called.
12. No cleanup path calls unloadBackgroundWebView.
13. The first CPM dispatch closure remains queued.

The retained state is:

m_backgroundWebView != nil
m_backgroundContentIsLoaded == false
m_actionsToPerformAfterBackgroundContentLoads is non-empty

For a lost-completion variant, serviceWorkerLaunchCompletionHandler is also still installed.

Every later tab

For each later CPM message from any tab sharing that context:

1. runtimeSendMessage resolves that tab normally.
2. Listener gating accepts RuntimeOnMessage.
3. wakeUpBackgroundContentIfNecessary again sees the background as not loaded.
4. It appends another dispatch closure to the same shared action vector.
5. loadBackgroundWebViewIfNeeded sees m_backgroundWebView != nil and returns.
6. No replacement worker is created.
7. No dispatch closure runs.
8. The content script's runtime.sendMessage promise remains pending.
9. The background never handles the CPM init.
10. The background never sends tabs.sendMessage(initResp).
11. Consent management does not start in that tab.

Because the queue and background view belong to the shared extension context, this repeats for every existing and newly created tab attached to the same controller. A page reload cannot repair it.

Recovery

This state ends only when something calls unloadBackgroundWebView or unloads/reloads the entire extension context. Relevant cleanup paths are:

• Background WebContent-process termination callback
• Background navigation failure callback
• Explicit extension-context unload/reload
• App process restart

[corrected] The 30-second eviction does recover this sequence. Only the first wake-up (view still nil) skips the timer; every later wake-up sees m_backgroundWebView != nil and arms it. Expected timeline: message 1 → load fails; message 2 → timer armed; +30 s → view unloaded; message 3 → fresh load. The debug simulation is one-shot (WebExtensionManager.swift:648-652), so it should recover on that schedule — verify empirically; persistence beyond that would mean shipping WebKit differs from trunk.

Opening an ordinary new browser window does not itself unload or reload the shared extension context. Therefore:

• If a new window works while the original remains broken, this exact all-tabs freeze is not the state currently being observed; the failure is more likely tab/process routing.
• If creating a new window reloads or replaces the extension context in the app's surrounding lifecycle, the new window can work because it is no longer using the poisoned context.
• The discriminator is whether previously broken tabs recover after the new window starts working.

Alternative extension-wide freeze without queued actions

A separate extension-wide failure is possible when the shared listener bookkeeping says RuntimeOnMessage is absent:

background worker was unloaded
m_backgroundContentHasLoadedOnce == true
RuntimeOnMessage absent from m_backgroundContentEventListeners

Every tab then follows:

runtimeSendMessage
-> wakeUpBackgroundContentIfNecessaryToFireEvents
-> listener considered absent
-> completionHandler called without waking worker
-> no background CPM handler
-> no initResp

This freezes CPM across all tabs without growing m_actionsToPerformAfterBackgroundContentLoads. It recovers only when another event loads the worker and repairs listener registration, or when the extension context is reloaded.

On WebKit versions before 7682d9817b, the same sequence can occur before the first successful background load because an empty persisted listener set was incorrectly considered authoritative.

Historical production trigger ranking (superseded)

Kept as investigation history. Do not use this section as the current conclusion; see Current working hypotheses (authoritative, 2026-09-09) above. Later validation rejected or demoted several entries.

Ordered by estimated probability of producing the observed "CPM dead in every tab, reload doesn't help" state on macOS. Line refs: WebKit trunk 0c7e7ad97b; details in cpm-web-extension-breakage-validation.

1. Critical memory pressure terminates the "idle" extension worker — source hypothesis, manual repro failed

This was initially ranked first from source reading. Running sudo memory_pressure -S -l critical on the target macOS 26.x system did not break CPM, so it is no longer an active reproduction candidate. Keep the chain below as a description of the source path, not evidence that production reaches the broken state.

Chain:

1. CPM context loaded; background SW registered and activated. ≥10 s pass. The SW server marks the worker idle (SWServerWorker::isIdle, SWServerWorker.cpp:341) — extension runtime.sendMessage traffic goes over WebKit IPC and never calls needsRunning(), so the worker is always idle from the server's view.
2. System memory pressure → Critical. The WebProcess hosting the SW page reports MemoryPressureStatusChanged (WebProcess.cpp:554).
3. WebProcessPool::memoryPressureStatusChangedForProcess: Critical && isRunningServiceWorkers() → NetworkProcess::TerminateIdleServiceWorkers(pid) (WebProcessPool.cpp:2937).
4. SWServer::terminateIdleServiceWorkers terminates the CPM worker (SWServer.cpp:1807).
5. WebProcess: worker thread stops, ServiceWorkerGlobalScope destroyed, Page::m_serviceWorkerGlobalScope → null. SW page, frame, and RuntimeOnMessage/Main listener entry survive.
6. UIProcess WebExtensionContext unchanged: m_backgroundWebView != nil, m_backgroundContentIsLoaded == true. No error recorded, no delegate callback.
7. Any tab, any frame: cpm.js → runtime.sendMessage(init) → runtimeSendMessage → tab found → listener present → wakeUpBackgroundContentIfNecessary re-arms the 30 s eviction timer → backgroundContentIsLoaded() true → DispatchRuntimeMessageEvent to the SW page process.
8. enumerateFramesAndNamespaceObjects → jsContextForServiceWorkerWorld → null → frame skipped → null reply → {} → content script's await sendMessage resolves undefined. No initResp; AutoConsent stays in waitingForInitResponse.
9. Every navigation in every tab repeats 7–8 and keeps re-arming the timer (all_frames: true makes this continuous while browsing).
10. Exit: ≥30 s with zero extension events → unloadBackgroundContentIfPossible → view unloaded → next message reloads a fresh worker (cpmMessagingRecoveredWithoutExtensionReload); or Fire/extension reload; or relaunch.

Repro:

1. Launch DDG, open one tab, wait ≥15 s.
2. sudo memory_pressure -S -l critical (simulate) or memory_pressure -l critical (real), hold ~5 s. Watch log stream --predicate 'subsystem == "com.apple.WebKit" AND (eventMessage CONTAINS "terminateIdleServiceWorkers" OR eventMessage CONTAINS "memoryPressureStatusChangedForProcess")'.
3. In Safari-style Web Inspector target list (Develop → DuckDuckGo) the "DuckDuckGo Embedded Extension — Extension Service Worker" target should disappear while the extension stays loaded.
4. Load any CMP page in any tab / new tab / new window → banner not handled; health monitor fires cpmInitializationFailed after 4 s, cpmMessagingStuck on the second navigation. WKWebExtensionContext.errors is empty; no "Tab not found" log line.
5. Stop navigating for ≥35 s, load a CMP page → works; cpmMessagingRecoveredWithoutExtensionReload.

2. Network process crash / unresponsive termination

Why second: less frequent than memory pressure, but every occurrence lands in the same dead-worker state; also fits an "after the network hiccuped, cookie banners stopped being handled" report.

Chain:

1. NetworkProcessProxy::didClose (crash), didBecomeUnresponsive (UIProcess kills it), or ExceededMemoryLimit.
2. UIProcess: WebProcessPool::networkProcessDidTerminate → terminateServiceWorkers() → WebProcessProxy::disableRemoteWorkers(ServiceWorker) → WebSWContextManagerConnection::Close to the SW page process (WebProcessPool.cpp:497-509, 1850; WebProcessProxy.cpp:3094). Process survives because it owns the SW page.
3. WebProcess: networkProcessConnectionClosed → SWContextManager::stopAllServiceWorkers() (WebProcess.cpp:1467).
4. Steps 5–10 of chain 1. The in-memory registration is gone; nothing re-registers until the view is recreated.

Repro: launch, wait 15 s, kill -9 DuckDuckGo's com.apple.WebKit.Networking process (pick the one whose parent is the DDG PID), wait for the network process to relaunch, then step 4–5 of chain 1.

3. Startup / session-restoration miss (transient, per-tab, very common)

Not the stuck state, but the most frequent CPM miss and the one most likely to be misread as stuck. Amplified by an app-side detail: the context's baseURL is a random UUID per WKWebExtensionContext object and the app never sets it, so every load runs _renameOrigin and content injection waits on a Network-process round trip (WebExtensionContextCocoa.mm:222, 297-311, 516-525).

Chain: launch → setupWebExtensions() → async loadAndSync() → restored tabs commit before addInjectedContent → no document_start → no CPM until reload. Recovery: any navigation after the extension finishes loading.

Repro: 10+ restored tabs, quit, relaunch; several restored tabs have no CPM until reloaded. Fix: set context.baseURL = webkit-extension://<uniqueIdentifier>/ in WebExtensionLoader.makeContext.

4. Tab/window routing: sender page not found

The only chain that explains "one window broken, new window fine". [corrected 2026-09-09] getCurrentTab iterates WebKit's own openTabs() = m_tabMap entries with m_isOpen && isValid() (WebExtensionContextCocoa.mm:1105-1114, 1251-1260; WebExtensionTabCocoa.mm:373), i.e. the set built by populateWindowsAndTabs() at load plus didOpenTab/didCloseTab afterwards — not a live query of the app's window provider. A Tab whose didOpenTab was dropped (droppedCallbacksCount), suppressed (withTabLifecycleEventsSuppressed), or followed by a stray didCloseTab, fails with runtime.sendMessage(): tab not found before any wake-up (WebExtensionContextAPIRuntimeCocoa.mm:141-147). Directly testable from the app: context.openTabs.contains { $0 === tab }. Trigger not identified in source; needs the "Tab not found for message for content script message" log correlated with window registration. Probability unknown; ranked here because it matches a reported observation, not because a trigger is known.

5. Repeatable registration failure (SW script unreadable)

The retained-failed-view state becomes persistent only if each retry fails. Only repeatable cause found: background-embedded.js is read from disk on every SW load, uncached (WebExtensionURLSchemeHandlerCocoa.mm:120, WebExtension::resourceDataForPath default CacheResult::No). If the installed extension directory is removed/unreadable while loaded, every retry → NSURLErrorFileDoesNotExist → completion(false). Content scripts (read at context load) keep running → exactly "content script talks, background silent". Unlike chains 1–2, errors contains BackgroundContentFailedToLoad on every retry. No in-app path deletes a loaded extension's files; external causes only. Low probability.

Repro: with the extension loaded, mv the public/js/background-embedded.js inside ~/Library/Application Support/DuckDuckGo/…/<uuid>/; wait for the worker to be evicted (30 s idle) or force via memory pressure; load a CMP page.

6. Transient registration failure (retained failed view, self-healing)

Debug-simulation shape. Any one-off _loadServiceWorker failure (Network-process disconnect mid-registration, etc.) retains the view, but the second message arms the eviction timer and the third message (≥30 s later) recovers. Visible as at most ~30 s of failure plus one extra navigation. Low impact.

7. Listener-gating freeze

RuntimeOnMessage absent from m_backgroundContentEventListeners after first load would drop every message before wake-up. Counts only decrement via JS removeListener, and the bundle never removes onMessage. No trigger found; theoretical.

Discriminating the three observable classes

Probe result after a stuck episode	Class
errors == [], probe runtime.sendMessage resolves undefined, no "Tab not found" log, SW inspector target gone	Dead worker under loaded view (chains 1, 2)
errors contains BackgroundContentFailedToLoad, repeating every ~30 s	Repeatable registration failure (chain 5)
Content script rejected with tab not found, log "Tab not found for message for content script message"	Routing (chain 4)

Diagnostics: what we have and what WebKit lets us add (2026-09-09)

What Site Breakage Reports carry today

BrokenSiteReport.swift:309-321 serialises CookieConsentInfo:

Param	Source	Discriminating power for the stuck state
consentManaged, consentOptoutFailed, consentSelftestFailed, consentReloadLoop, consentRule, consentHeuristicEnabled	background → native refreshDashboardState	Only populated if the background processed init. In every stuck chain they stay at defaults.
cpmDashboardState	.waiting set per navigation (PrivacyDashboardTabExtension.swift:185), .applied when the background answers	waiting = "background never processed init for this document". Cannot say why.
cpmStage	background (not_started, config_unavailable, settings_missing, setting_disabled, site_disabled, init_received, popup_found, optout_failed, done)	not_started in every stuck chain (it is the app default, never overwritten).
cpmErrors	background: tab_<method> / glob_<method> native-messaging timeouts, multiple_cmps (background-embedded.js:2926, 2803)	Background → native failures only. Empty in every content→background failure.
cpmQueueSize, cpmConfigVersion	background	Same — absent when the background is silent.
cpmExtensionLoaded	controller.extensionContexts contains the embedded type (WebExtensionManaging.swift:174)	UIProcess "context loaded". True in chains 1, 2, 4, 5 — it does not see a dead worker, a retained failed view, or a missing tab. Only false during the Fire/reload window.
cpmExtensionDroppedCallbacks	WebExtensionEventsListener calls made while controller == nil	Only meaningful for chain 4 (missed didOpenTab), and only if the drop happened while controller was nil.

Net: a stuck-state report reads cpmDashboardState=waiting, cpmStage=not_started, cpmExtensionLoaded=1, cpmErrors="" for chains 1, 2, 4, 5 alike, and also for "content script never injected" (chain 3). Nothing in the report separates the five. Everything below is about adding that separation.

Hooks per hypothesis

Legend: P = public API, S = SPI (same class as the _webExtensionController:didCreateBackgroundWebView: selector the app already uses), L = readable from the app's own OSLogStore, E = extension (JS) change.

Chain 1/2 — worker terminated under a "loaded" background view

WebKit gives the app nothing directly: no delegate, no notification, no error. Indirect signals:

• S WKWebExtensionContext._backgroundWebView (WKWebExtensionContextPrivate.h:38), or keep the WKWebView handed to didCreateBackgroundWebView (the app already receives it). Then, with P callAsyncJavaScript on that view (it is the generated SW page, main world): const r = await navigator.serviceWorker.getRegistration(); return { hasRegistration: !!r, state: r?.active?.state ?? null, controller: !!navigator.serviceWorker.controller } – hasRegistration == false while context.errors is empty ⇒ chain 2 (registration was in-memory in the dead Network process). – hasRegistration == true, state == "activated" while the content-script probe (below) gets undefined ⇒ chain 1 (worker killed, registration intact). The client-side ServiceWorker.state does not reflect termination, so this needs the probe pair, not the state alone. Pixel params: cpmBgViewExists, cpmBgSwRegistration, cpmBgSwState.
• S WKWebsiteDataStore.default()._networkProcessIdentifier / _networkProcessExists (WKWebsiteDataStorePrivate.h:124-126, macOS 12+). Record at context load; on a stuck episode compare. PID changed ⇒ Network process restarted ⇒ chain 2. Param: cpmNetworkProcessRestarted (+ seconds since).
• L NetworkProcessProxy::didClose logs RELEASE_LOG_ERROR(Process, "... NetworkProcessProxy::didClose (Network Process %d crash)") (NetworkProcessProxy.cpp:525) and didBecomeUnresponsive logs an error too (:183). These run in the app process, so OSLogStore(scope: .currentProcessIdentifier) with predicate subsystem == "com.apple.WebKit" AND category == "Process" returns them without entitlements. Param: cpmNetworkProcessCrashCount in the last N minutes.
• P app-side DispatchSource.makeMemoryPressureSource(eventMask: [.warning, .critical]) — the same kernel event the WebProcess reacts to in chain 1. Record timestamp of last .critical. Params: cpmMemPressureCriticalRecently, cpmSecondsSinceCritical. This is the single most valuable new field for chain 1 and costs nothing.
• S WKWebView._webProcessIdentifier (WKWebViewPrivate.h:226) on the retained background view: 0 ⇒ SW-page process gone (WebKit does handle that case via webViewWebContentProcessDidTerminate, so it should be rare — useful as a sanity check). Param: cpmBgProcessAlive.
• P WKWebExtensionContext.loadBackgroundContent(completionHandler:) — returns immediately with nil in chains 1/2 (WebKit thinks it is loaded), with the load error in chain 5, never/late in chain 6. Param: cpmBgLoadProbe = ok | error:<code> | timeout.
• E + P Content-script probe: evaluate in the extension's content world from the app — WKContentWorld.world(name: "WebExtension-\(context.uniqueIdentifier)") maps to the same API::ContentWorld::sharedWorldWithName WebKit uses for injection (WebExtensionContextCocoa.mm:293, WKContentWorld.mm:59-64). Have cpm.js publish globalThis.__ddgCPM = { injectedAt, lifecycle, initSentAt, initResp: bool, lastSendError } (a few lines; sendContentMessage currently awaits without a catch, cpm.js:3393-3398). Then evaluateJavaScript("globalThis.__ddgCPM", in: nil, in: world) from the tab yields: – undefined ⇒ content script never injected ⇒ chain 3 (startup/Fire window) — cpmContentScriptInjected=0. – lifecycle == "waitingForInitResponse", lastSendError == null ⇒ background silent ⇒ chains 1/2/5 (use the other params to split). – lastSendError contains tab not found ⇒ chain 4. Do not use typeof chrome as the marker: evaluating in the world can itself trigger globalObjectIsAvailableForFrame and inject the browser namespace.

Recovery, not just diagnosis (chain 1): from the SW page, r.active.postMessage({type:"ping"}) goes through the SW server (SWServer::runServiceWorkerIfNecessary, SWServer.cpp:1221), which starts a not-running worker. On start, ServiceWorkerGlobalScope::notifyServiceWorkerPageOfCreationIfNecessary re-binds the page and fires dispatchServiceWorkerGlobalObjectAvailable → serviceWorkerGlobalObjectIsAvailableForFrame re-installs browser (ServiceWorkerGlobalScope.cpp:118-132, WebLocalFrameLoaderClient.cpp:1968-1980) and the background script re-runs, re-registering onMessage. That would revive CPM without unloading the context. Needs a manual test; if it works it is a one-line remediation on cpmMessagingStuck. It cannot help chain 2 (no registration) — that needs the context reload.

Chain 3 — content script not injected (startup / Fire / reload window)

• P WKWebExtensionContext.isLoaded and hasInjectedContent(for: url) at navigationCommitted. Param: cpmContextLoadedAtCommit, cpmInjectedContentForURL.
• E + P the content-world probe above (cpmContentScriptInjected).
• P timing: Date() at controller.load(context) minus the first loadBackgroundContent completion = time the _renameOrigin gate held the load. Param: cpmContextReadyMs. Expect this to collapse once baseURL is set.
• Already available: WebExtensionLifecycleEvent stream (loaded/willReload/reloaded/reloadFailed) — attach cpmMsSinceLastReload to the report.

Chain 4 — tab not resolvable

• P WKWebExtensionContext.openTabs (WKWebExtensionContext.h:683) → openTabs.contains { $0 === currentTab }. This is exactly the set getCurrentTab searches. Param: cpmTabKnownToWebKit. Also openWindows.contains(windowController): cpmWindowKnownToWebKit.
• L RELEASE_LOG_ERROR(Extensions, "Tab not found for message for content script message") (WebExtensionContextAPIRuntimeCocoa.mm:144) is emitted in the app process → OSLogStore predicate category == "Extensions" AND eventMessage CONTAINS "Tab not found". Param: cpmTabNotFoundLogCount.
• Already available: cpmExtensionDroppedCallbacks (keep).

Chain 5 — repeatable registration failure

• P WKWebExtensionContext.errors + WKWebExtensionContext.errorsDidUpdateNotification (WKWebExtensionContext.h:73, 179). Serialise code (WKWebExtensionContextErrorBackgroundContentFailedToLoad = 6) and the underlying NSError domain/code (NSURLErrorFileDoesNotExist, etc.). Param: cpmContextErrors = "6:NSURLErrorDomain/-1100".
• S count didCreateBackgroundWebView callbacks per context lifetime: >1 means WebKit is retrying background loads. Param: cpmBgViewCreateCount.
• L WebExtensionContext::recordError logs RELEASE_LOG_ERROR(Extensions, "Error recorded: …") (WebExtensionContextCocoa.mm:283) — redundant with errors, but timestamps each retry.
• P FileManager.default.isReadableFile(atPath: installedPath/public/js/background-embedded.js) at report time. Param: cpmBundleReadable.

Chain 6 — transient registration failure

Covered by cpmContextErrors + cpmBgViewCreateCount; the health monitor's recoveredWithoutExtensionReload closes it.

Chain 7 — listener gating

No hook; m_backgroundContentEventListeners is not exposed. If everything else reads healthy (cpmBgSwRegistration=1, content-script probe shows waitingForInitResponse, errors == [], no memory pressure, no Network restart, background revives on postMessage), this is the residual bucket.

What is not catchable from the app

• SW-server side logs (SWServer::terminateIdleServiceWorkers, runRegisterJob) live in the Network process; OSLogStore only covers our own PID without the com.apple.private.logging.* entitlement. log collect from users' machines is the only route.
• RELEASE_LOG_DEBUG lines ("Loading background content", "Background content loaded", "Scheduling background content to unload") are debug level and not persisted unless the device has WebKit logging enabled; do not depend on them.
• There is no notification for background-view unload/reload or for worker start/stop.

Suggested minimal pixel/report additions (ranked by value ÷ cost)

1. cpmMemPressureCriticalRecently + cpmSecondsSinceCritical — public, in-app, ~20 lines. Separates chain 1.
2. cpmNetworkProcessRestarted (PID compare) or cpmNetworkProcessCrashCount (OSLogStore) — separates chain 2.
3. cpmContextErrors + cpmBgViewCreateCount — separates chains 5/6.
4. cpmTabKnownToWebKit + cpmTabNotFoundLogCount — separates chain 4.
5. cpmContentScriptInjected / cpmContentScriptLifecycle / cpmLastSendError via the content-world probe — separates chain 3 and confirms "background silent" for the rest. Needs the small cpm.js global.
6. cpmBgSwRegistration / cpmBgSwState via the SW-page probe — confirms 1 vs 2. SPI-adjacent (needs the background WKWebView reference).

Items 1–4 are enough to attribute the current stuck pixels; 5–6 turn the health monitor into a classifier instead of a timer.

Investigation update: rejected triggers and JavaScript paths (2026-09-09)

Rejected or demoted production triggers

• Critical memory pressure is not an active reproduction candidate. Running sudo memory_pressure -S -l critical did not break the extension and CPM continued working. The source-level termination path remains real, but the proposed user-reachable sequence was not reproduced on the target system and must not be ranked as the most probable cause without new evidence.
• Cold launch before WebKit fix 7682d9817b is transient. It reproduces a missed initial message but recovers on the next navigation. It does not explain persistent cross-tab breakage.
• Feature flags are not toggled for production users. Flag transition scenarios are test controls, not plausible production triggers.
• Privacy-config scriptlet refresh does not reload the embedded CPM extension. ScriptletConfigProvider.privacyFeature(for:) maps only .adBlockingExtension; .embedded returns nil. The update chain (privacyConfigurationManager.updatesPublisher -> ScriptletManager.refreshAllActiveExtensions -> WebExtensionScriptletCoordinator -> reloadExtension(.adBlockingExtension)) unloads/reloads only the ad-blocking extension context. CPM config itself is fetched by the already-running embedded background worker and does not replace that context.

Can JavaScript in a site freeze CPM?

A synchronous infinite loop or very long task in page JavaScript blocks the tab's WebContent main thread. CPM runs in an isolated world but on that same thread, so its content script in that document also stops. This explains a per-tab failure, not an extension-wide background freeze.

The background view is not related to an ordinary tab. WebExtensionContext::relatedWebView() enumerates only extension-origin pages; _relatedWebView is weak and is used for process grouping. Therefore a normal site's JavaScript does not place the hidden background view in the same WebContent process through this mechanism.

Page JavaScript can affect the background indirectly by generating extension traffic. CPM is injected with all_frames: true; every new or navigated frame sends init. A page that continuously creates, destroys, or navigates frames can produce an unbounded stream of runtime.sendMessage events. For each frame the background starts an async CPM handler, performs native queries, filters compact rules, and sends a rules/config payload back. There is no global admission limit or backpressure. This can:

1. keep restarting WebKit's 30-second background eviction timer;
2. create many concurrent async handlers and native requests;
3. monopolize the background worker event loop and delay messages from all tabs.

This is currently a starvation hypothesis, not a permanent-state explanation. Once the frame storm stops, queued work should drain and the worker should recover unless the load/event bookkeeping enters a separate WebKit failure state. A stable repro should therefore compare behavior while the producer tab is open, after it is closed, and after 35 seconds with no extension events.

An arbitrary unresolved Promise does not block a JavaScript event loop. To freeze the background worker itself requires synchronous non-yielding work, runaway task production faster than it can drain, or a WebKit/JSC deadlock.

The current compactRuleList URL regular expressions were checked as a concrete synchronous-hang candidate: 569 unique patterns were matched against adversarial URLs up to 100 KB in isolated workers. No match exceeded 0.27 ms and none timed out. Catastrophic regexp backtracking is therefore not supported by the current config.

Background-worker JavaScript freeze

A synchronous long task inside background-embedded.js does match the all-tabs symptom:

background event loop stops
-> every tab's RuntimeOnMessage is dispatched to the same worker
-> handlers cannot execute or reply
-> no initResp and no native dashboard update
-> incoming events keep the background view's eviction timer refreshed
-> all tabs remain affected while traffic continues

WebKit does not automatically terminate this particular unresponsive process. WebProcessProxy::didBecomeUnresponsive auto-terminates only a worker-only process whose m_pageMap is empty. The extension service worker is hosted through a hidden WKWebView, so the process has a page and WebKit only reports unresponsiveness to the navigation client. DuckDuckGo has no handler for the private unresponsive callback. Current bundle inspection found no reachable infinite loop at worker startup or in CPM message routing; the iframe/message storm remains the concrete production-input candidate.

What retains the background WKWebView

There is one direct WebKit owner:

WKWebExtensionController
-> WebExtensionController::m_extensionContexts
-> WebExtensionContext::m_backgroundWebView (RetainPtr<WKWebView>)

The app also keeps the controller/context loaded for the browser lifetime. The view is released only when WebExtensionContext::unloadBackgroundWebView() closes it and assigns nil, or when the whole context is unloaded.

Additional lifetime mechanisms are:

• m_backgroundWebViewActivity holds a foreground process activity assertion. It keeps the WebContent process runnable; it is not another WKWebView owner.
• The background configuration disables hidden-page timer throttling, visibility-based process suppression, and inactive scheduling. These preserve execution, not object ownership.
• A pending _loadServiceWorker completion captures protectedThis = Ref { *this }; WebPageProxy::serviceWorkerLaunchCompletionHandler owns that block. This can keep the context alive if registration never settles. The context then keeps m_backgroundWebView alive. In the normal controller-loaded case this is an additional cycle, not the root owner.
• Pending m_actionsToPerformAfterBackgroundContentLoads closures retain their message completions and often a protected context until the background load completes or the context unloads. The vector belongs to the context; it does not independently own the view.
• Open active extension ports, pending permission requests, active inspection, an inspector background page, and repeated extension events cause unloadBackgroundContentIfPossible() to postpone or continually re-arm eviction. They do not add a strong view reference, but they make the context retain its view longer.
• WKWebViewConfiguration._relatedWebView, the background navigation/UI delegates, WebPageProxy::cocoaView, and the CPM diagnostics recorder are all weak in the relevant direction. The recorder stores currentBackgroundWebView weakly and its live-view list uses WeakBox; it does not perturb the lifecycle.

The practical distinction is: almost everything suspected of "retaining" the view merely prevents unloadBackgroundWebView() from being called. The only direct strong view reference found in WebKit's extension layer is WebExtensionContext::m_backgroundWebView.

Next steps (2026-09-09)

Ordered so each step de-risks the next. Days are rough effort, not calendar.

Phase 0 — confirm trunk matches shipping WebKit (½ day, manual, no code)

1. Debug sim persistence: enable "fail CPM background load", load one CMP page (fails), wait 35 s without navigating, load again. Expected: recovers. If it stays broken, shipping WebKit lacks the idle-eviction-on-wake-up path and chain 5/6 ranking changes.
2. Chain 1 repro: launch, wait 15 s, sudo memory_pressure -S -l critical for ~5 s, load a CMP page. Expected: no banner handling, errors empty, SW inspector target gone, recovery after 35 s idle.
3. Chain 2 repro: kill -9 DDG's com.apple.WebKit.Networking, load a CMP page. Same expectation.
4. Chain 1 revive test: after step 2, in the background WKWebView (grab it from didCreateBackgroundWebView behind a debug flag) run navigator.serviceWorker.getRegistration().then(r => r.active.postMessage({type:"ping"})), then load a CMP page. If CPM works again, we have a remediation that avoids the reload window.

Outcome: which chains are real on macOS 26.x, and whether postMessage revive is viable.

Phase 1 — attribution in existing pixels (2–3 days)

Add to CPMMessagingHealthMonitor failure/stuck/recovered pixels and to BrokenSiteReport:

1. cpmMemPressureCriticalRecently / cpmSecondsSinceCritical — in-app DispatchSource.makeMemoryPressureSource.
2. cpmNetworkProcessRestarted — compare WKWebsiteDataStore.default()._networkProcessIdentifier against the value recorded at context load (SPI; fall back to OSLogStore crash-line count if SPI is off the table).
3. cpmContextErrors (errors codes + underlying NSURLError) and cpmBgViewCreateCount (count didCreateBackgroundWebView).
4. cpmTabKnownToWebKit (context.openTabs.contains(tab)) and cpmTabNotFoundLogCount (OSLogStore, own PID, category == "Extensions" AND eventMessage CONTAINS "Tab not found").
5. cpmContextLoadedAtCommit, cpmMsSinceLastReload.

Ship behind the existing pixel plumbing; no extension change needed. After one release the stuck pixels split into chains 1 / 2 / 3 / 4 / 5.

Phase 2 — probes that classify at failure time (2–3 days, needs cpm.js + app)

1. cpm.js: publish globalThis.__ddgCPM = { injectedAt, lifecycle, initSentAt, gotInitResp, lastSendError }; wrap the sendMessage await in try/catch to capture tab not found.
2. App: on cpmInitializationFailed, evaluate globalThis.__ddgCPM in WKContentWorld.world(name: "WebExtension-\(uniqueIdentifier)") for the failing tab; attach cpmContentScriptInjected, cpmContentScriptLifecycle, cpmLastSendError.
3. App: on cpmMessagingStuck, run the SW-page probe on the background web view (hasRegistration, active.state) and loadBackgroundContent with a 2 s timeout; attach cpmBgSwRegistration, cpmBgLoadProbe.

Outcome: health monitor becomes a classifier; every stuck pixel names its chain.

Phase 3 — fixes (in order of confidence)

1. Stable base URL (½ day): context.baseURL = URL(string: "webkit-extension://\(identifier)/") in WebExtensionLoader.makeContext. Removes _renameOrigin from every load, shrinks the startup miss window (chain 3), and stops migrating extension web storage on every launch. Verify existing storage.local is unaffected (it is SQLite, not origin-keyed web storage) and that the first launch after the change performs one final rename from the last random URL.
2. Self-heal on stuck (1 day): on cpmMessagingStuck, if Phase 0 step 4 works → postMessage revive first; else reloadExtension(identifier:, trigger: .healthRecovery). Gate by a 5-minute cooldown; fire cpmMessagingRecoveredAfterExtensionReload (already exists).
3. Content-script retry (½ day, cpm.js): if no initResp within ~3 s, resend init (max 2–3 times, backoff). Covers chain 6 and any transient drop, and gives chain 1/2 a natural retry after the 30 s eviction instead of waiting for the next navigation.
4. Keep the worker alive (research, 1 day): the SW server only refreshes needsRunning() on server-routed events. A background chrome.alarms tick does not go through the SW server either. Options: (a) from the SW page, periodic registration.active.postMessage keep-alive — would also count as "not idle" for terminateIdleServiceWorkers; (b) file a WebKit bug: extension service workers should be exempt from terminateIdleServiceWorkers/terminateServiceWorkers, or WebExtensionContext should observe worker termination and unload/reload the background view. (b) is the real fix; (a) is the interim.
5. Tab registration audit (only if Phase 1 shows chain 4 volume): log every didOpenTab/didCloseTab with tab id in debug builds and diff against context.openTabs on stuck.

WebKit bug reports to file (after Phase 0 confirms)

1. Extension background service worker terminated by terminateIdleServiceWorkers / terminateServiceWorkers while WebExtensionContext keeps m_backgroundContentIsLoaded == true; messages resolve undefined with no error. Attach chain 1 and 2 repro steps.
2. _loadServiceWorker failure path does not schedule scheduleBackgroundContentToUnload(), so recovery depends on a second message arriving (minor).
3. Documentation/API request: a delegate callback or notification for background content load/unload and worker start/stop.

Status 2026-09-09 (evening)

Manual checks on shipping WebKit (macOS 26.x)

Check	Result	Meaning
Debug sim, wait 35 s idle, navigate	recovered	Idle eviction in wakeUpBackgroundContentIfNecessary is present in shipping WebKit; retained-failed-view is self-healing, as traced.
sudo memory_pressure -S -l critical, then CMP page	CPM kept working	Chain 1 not reproduced. Either memoryPressureStatusChangedForProcess → TerminateIdleServiceWorkers is not in this WebKit (it is under ENABLE(WEB_PROCESS_SUSPENSION_DELAY), recent), or -S did not reach the WebContent process. Verify with log stream --predicate 'process CONTAINS "WebKit.Networking" AND eventMessage CONTAINS "terminateIdleServiceWorkers"'; until then chain 1 is downgraded to "future macOS".
Network process kill (Debug → "Terminate WebKit Network Process", _terminateNetworkProcess)	CPM kept working	Chain 2 not reproduced either. Snapshot after the kill: network_process_restarted=true, extension_context_errors=none, background_view_alive=true, background_view_create_count=3_to_5. The background view had been recreated during the session, so WebKit recovers on its own here — via idle eviction or via webViewWebContentProcessDidTerminate/didFailNavigation of the SW page; which one is not yet known (recorder now logs web-process PID and Network PID per creation to tell them apart). WebKit XPC processes are launchd children (ppid 1), so they cannot be found by parent PID.

Conclusion so far: on shipping macOS 26.x WebKit, none of the traced "dead worker" triggers reproduce and the retained-failed-view state self-heals. There is currently no reproduced trigger for the stuck state; the chains below remain hypotheses ranked by source reading, not by evidence. Fix proposals are parked until a reproduction or production classification exists.

Implemented (branch cpm-breakage-pixel, not yet compiled here — build before trusting)

SharedPackages/WebExtensions:

• Autoconsent/CPMMessagingDiagnostics.swift — the fact struct and its bucketed, PII-free pixelParameters.
• Autoconsent/CPMMessagingDiagnosticsRecorder.swift — CPMMessagingDiagnosticsProviding + recorder: critical-memory-pressure dispatch source; Network-process PID at context load vs now (_networkProcessIdentifier via guarded KVC); errorsDidUpdateNotification observer; background web view create count, current view (weak), leak count via onDeinit and a weak list, _webProcessIdentifier liveness; openTabs membership; probes: loadBackgroundContent with timeout, navigator.serviceWorker.getRegistration() in the background page, globalThis.__ddgCPM in WKContentWorld.world(name: "WebExtension-<uniqueIdentifier>").
• CPMMessagingHealthMonitor.diagnosticsProvider — failure pixels get content-script probe + snapshot; stuck pixels also get background probes. Without a provider behaviour is unchanged (tests rely on that).
• WebExtensionPixelEvent.cpmInitializationFailed/.cpmMessagingStuck carry diagnostics:; CPMWebExtensionPixelMetadata.parameters renders them.
• WebExtensionManager: owns the recorder, feeds willLoad, unload (uninstall / unloadAll / reload) and the private didCreateBackgroundWebView delegate into it.

macOS:

• WebExtensionManagerFactory creates the recorder with a Tab.uuid → Tab resolver (WindowControllersManager.loadedTab(withUUID:), new).
• Debug menu: "Terminate WebKit Network Process", "Print CPM Diagnostics Snapshot".

Tests: CPMMessagingDiagnosticsTests (bucketing, sanitization, descriptors, recorder lifecycle), CPMMessagingHealthMonitorDiagnosticsTests (async attachment, probe levels).

Pixel parameters now attached

extension_context_loaded, memory_pressure_critical (none/under_1_min/under_5_min/under_30_min/over_30_min), network_process_restarted, extension_context_errors (background_failed_to_load:NSURLErrorDomain:-1100 style, or none), background_view_create_count (0/1/2/3_to_5/over_5), background_view_alive, background_view_leaked_count, background_web_process_alive, tab_known_to_webkit, content_script (present/marker_absent/unavailable), content_script_lifecycle, content_script_init_response, content_script_send_error (none/tab_not_found/extension_id_mismatch/other); stuck only: background_load_probe (loaded/failed:/timed_out/unavailable), background_sw_registration (present/missing), background_sw_state.

Required extension change (probe 1 reads marker_absent until this ships)

In the autoconsent content script (cpm.js source, shared/js/cpm.js in the extension repo), publish the marker on the isolated-world global:

globalThis.__ddgCPM = { injectedAt: Date.now(), lifecycle: 'created', receivedInitResponse: false, lastSendError: null };

const consent = new AutoConsent(async (msg) => {
  try {
    await chrome.runtime.sendMessage({ messageType: 'autoconsent', autoconsentPayload: msg });
  } catch (e) {
    globalThis.__ddgCPM.lastSendError = String(e && e.message || e);
  }
});
chrome.runtime.onMessage.addListener((message) => {
  if (message && message.type === 'initResp') globalThis.__ddgCPM.receivedInitResponse = true;
  return Promise.resolve(consent.receiveMessageCallback(message));
});
// in AutoConsent.updateState({ lifecycle }): globalThis.__ddgCPM.lifecycle = lifecycle;

Keys read by the recorder: lifecycle (string), receivedInitResponse (bool), lastSendError (string|null). Values are sanitized/classified before reaching the pixel.

Added after the Network-kill check

• Recorder logs (level info, [CPM Diagnostics]) on every background view creation: previousViewAlive, previousWebProcessPID, previousWebProcessAlive, secondsSincePreviousCreation, networkProcessPID, networkProcessChangedSinceLastCreation, then the new view's webProcessPID one turn later. A recreation with previousWebProcessAlive=false or a changed web-process PID means the SW page process died (WebKit's webViewWebContentProcessDidTerminate path); previousWebProcessAlive=true with ≥30 s gap means idle eviction.
• "Terminate WebKit Network Process" prints a diagnostics snapshot before killing, so before/after can be compared.
• No event hook exists for Network-process termination in the app; WebKit's own NetworkProcessProxy::didClose error line is visible in Console.app (subsystem == "com.apple.WebKit", category Process) but is not captured by the recorder.

Next (data first, no fixes yet)

1. Repeat the Network-kill with the new logging; read whether the recreation right after the kill is process-death or eviction.
2. Build, run WebExtensions tests, land the diagnostics; add the __ddgCPM marker to cpm.js.
3. Read debug_web_extension_cpm_messaging_stuck_* parameters after a release to see which class exists in production.
4. Show the diagnostics parameters in the internal-user stuck notification so reports arrive classified.

Not done on purpose

• OSLogStore-based counters (per request).
• iOS wiring (factory passes no recorder; behaviour unchanged there).
• Breakage-report fields — CPMMessagingDiagnosticsRecorder.snapshot().pixelParameters is ready to be merged into CookieConsentInfo when wanted.

New failure class: background → app native messaging (2026-09-09, late)

Found by reading the actual init handler in background-embedded.js instead of WebKit. This class needs no WebKit anomaly and produces the exact all-tabs symptom and the exact health-monitor "stuck" signature.

Mechanism (extension side, background-embedded.js)

handleAutoConsentMessage (2537) awaits three native requests before it ever sends initResp: remoteConfigJson (getResourceIfNew, 2555), checkAutoconsentSetting (isAutoconsentSettingEnabled, 2590), checkAutoconsentEnabledForSite (isFeatureEnabled, 2613). _request (2954) swallows any error or 20 s timeout and returns undefined; checkAutoconsentSetting turns that into { enabled: false } (3040) → heuristic mode "" → "autoconsent setting not enabled" → return without initResp (2592-2606). The follow-up refreshDashboardState(setting_disabled) is itself a native call, so when native messaging is broken nothing reaches the app → the health monitor sees no dashboard response → cpmInitializationFailed → cpmMessagingStuck. Every tab, every navigation, until the extension is reloaded. Content↔background works fine the whole time, so all WebKit-side probes read healthy.

App side: how native messaging breaks

WebExtensionContext::sendNativeMessage calls the controller delegate directly (WebExtensionContextAPIRuntimeCocoa.mm:338), no permission or app-id check. The app (WebExtensionManager+NativeMessaging.swift:122-151) routes by (context.uniqueIdentifier, featureName) and returns nil on .noHandler and .failure; the extension turns nil into throw "unexpected response type" → undefined → disabled. Handlers exist only if willLoad registered them for the live context's identifier.

Paths that remove handlers while a context stays loaded:

• reloadExtension(identifier:) (WebExtensionManager.swift:414-449): unload → unregisterHandlers → loadWebExtension. WebExtensionLoader.loadWebExtension has an idempotent branch (WebExtensionLoader.swift:70-84): if a context with that identifier is already in the controller it returns without calling willLoad → handlers stay unregistered. Reachable when another load of the same identifier interleaves between the unload and the load (e.g. scriptlet-triggered reloadExtension(for:) from WebExtensionScriptletCoordinator.swift:165 racing the Fire reloadInstalledExtensions; the coordinator serializes only its own ops). Pinned by testWhenExtensionIsAlreadyLoaded_ThenSecondLoadDoesNotCallDelegate.
• Any future code path calling unregisterHandlers without a matching willLoad.

Also possible without unregistering: a handler that never replies (delegate is async; a hang on the main actor) → 20 s timeout per request → three requests per init → same "disabled" outcome ~60 s later.

Deterministic reproduction (added)

Debug → Web Extensions → Break CPM Native Messaging (unregister handlers) (WebExtensionManager.unregisterNativeMessageHandlersForDebugging). Then load a CMP page in any tab/window: banner not handled everywhere; Console shows ⚠️ No handler for extension '<uuid>' feature 'autoconsent'; snapshot shows native_handler_registered=false with everything else green; health monitor fires initialization_failed then stuck. Reload the extension from the debug menu → recovers. This is the first reproduction that matches the production signature end to end.

Diagnostics added

native_handler_registered (router lookup identical to routeMessage) in snapshot/pixels. In production stuck pixels, native_handler_registered=false = this class; =true with all probes green points at the timeout variant (handler hang) or at the content-script marker being absent.

What this does and does not prove

Proves the class produces the symptom and that the code has a path (idempotent load after unregister) that leaves the live context without handlers. Does not yet prove that path fires in production — that is what native_handler_registered in the stuck pixels and Console No handler for extension lines on internal machines will tell.

Correction and a traced production path (2026-09-09, night)

What "Break CPM Native Messaging" is and is not

It only reproduces the end state (context loaded, no native handlers). It does not model Fire or any other real path. Traced every unregisterHandlers / willLoad pairing for the CPM context: Fire (unloadAllExtensions → reloadInstalledExtensions/loadInstalledExtensions), syncEmbeddedExtensions upgrade, launch loadAndSync, flag-off uninstall — all re-register or unload the context together. The idempotent-load race needs a concurrent reloadExtension(identifier:), which in production only the scriptlet coordinator issues, and scriptlets exist only for adBlockingExtension (ScriptletConfigProvider.swift:70-77). No production path to the no-handler state was found for CPM. The class stays as a mechanism (native failure ⇒ background disables itself, no initResp) with only the "handler does not answer within 20 s" variant left, which is transient.

Traced path that does reproduce "old tabs dead, new tabs fine": controller replacement

A tab's WKWebViewConfiguration.webExtensionController is set once, at tab creation, from NSApp.delegateTyped.webExtensionManager?.controller (WKWebViewConfigurationExtensions.swift:74-76). The manager — and with it the WKWebExtensionController — is created/destroyed by the webExtensions feature flag (AppDelegate.swift:2063-2127):

• flag off: handleWebExtensionsFlagDisabled → uninstallAllExtensions() (unloads contexts from controller A) → webExtensionManager = nil.
• flag on: initializeWebExtensions() → new manager, new controller B → loadAndSync loads CPM into B.

Every tab created while the manager was nil has no controller; every tab created before an off→on cycle keeps controller A with zero contexts. In both cases nothing is ever injected into those tabs again: page reload does not help, the health monitor times out on every navigation (extensionIsLoaded reads the new manager → true → 4 s grace → initialization_failed → stuck), new tabs/windows work (recovered_without_reload). This is the only chain so far that reproduces the reported window-scoped observation.

The flag is remoteReleasable(WebExtensionsSubfeature.featureEnabled) (FeatureFlag.swift:612). It changes mid-session on any privacy-config refresh that flips it: rollout ramp (user enters the cohort while the app is running → all existing tabs, including the restored session, never get CPM), remote kill-switch off→on, internal-user overrides. .removeDuplicates() on the publisher means only real flips fire, but a single flip is enough.

Also covered by the same mechanism: tabs restored at launch before the manager exists (acknowledged in the code comment at AppDelegate.swift:2088-2089), when the flag is off at startup and turns on later.

Reproduction (deterministic, uses existing internal debug menu)

1. Launch with the webExtensions flag ON. Open two tabs on CMP sites, confirm CPM works.
2. Debug → Feature Flags → turn webExtensions OFF, then ON again. (uninstallAll → manager nil → new manager/controller, extensions reinstalled.)
3. In the two old tabs navigate to CMP sites: banners not handled, reload does not help. initialization_failed → stuck.
4. Open a new tab/window with a CMP site: works; recovered_without_reload. Return to the old tabs: still broken, new failures → new episode. Variant: start with the flag OFF, open tabs, turn ON — the tabs opened before never get CPM.

Diagnostic added

tab_controller_matches_context = tab.webView.configuration.webExtensionController === context.webExtensionController. false in a stuck pixel is this chain, unambiguously. Combined with native_handler_registered and the WebKit probes this now separates: controller mismatch (this) / no native handler / registration failure / dead worker / routing.

Open question that decides the fix design

Is CPM breakage in production reported for old tabs only (consistent with this chain) or for new tabs too? The stuck/recovered pixel sequence with tab_controller_matches_context answers it. Fix design deferred until that is known, per agreement.

Controller-replacement chain: not triggered in production (checked 2026-09-09)

• privacy-configuration/overrides/macos-override.json: webExtensions block (enabled, minSupportedVersion 1.183.0, subfeature embedded: enabled) unchanged since June; no commit touched it.
• App flag .webExtensions = remoteReleasable(webExtensions.featureEnabled), defaultValue: .enabled. featureEnabled is absent from the config → .disabled(.featureMissing) → default → true (AppPrivacyConfiguration.swift:191-197, FeatureFlagger.swift:431-432). Stable across launches and config reloads; .removeDuplicates() suppresses repeats. Only a parent-state change or an internal override can flip it.
• Browser update: bundle swap happens at relaunch; on first launch of the new version the old UUID loads, then syncEmbeddedExtensions installs/loads the new UUID into the same controller and unloads the old. Documents holding old-context content scripts lose messaging until their next navigation — transient. Handlers are keyed by UUID; nothing from the previous version lingers.

Status: memory pressure, Network-process death, lost native handlers and controller replacement are all either not reproducible on shipping WebKit or not triggered by production conditions. Retained-failed-view self-heals. Next input must be production data: cpm_messaging_stuck_<reason> split and recovered-with/without-reload ratio; breakage-report split of cpmDashboardState=waiting vs applied + cpmStage ∈ {setting_disabled, config_unavailable, settings_missing}.

Traced production path: removeAllUserScripts() strips the extension's content scripts from a tab (2026-09-09, late night)

Mechanism (WebKit)

WebKit injects an extension's content scripts into a WKUserContentController exactly once per controller: when the controller is first seen (WebExtensionController::addUserContentController, WebExtensionController.cpp:303-320 → WebExtensionContext::addInjectedContent(ucc), WebExtensionContext.cpp:1459) and again for all known controllers when the context (re)loads or its match patterns change. Nothing re-injects on navigation. Any app call to WKUserContentController.removeAllUserScripts() on a tab's controller therefore removes cpm.js (and the ad-blocking scriptlets, Dark Reader) from that tab until the extension context is reloaded (Fire) or the app relaunches. The tab's WKWebView, its controller and hasInjectedContent all look healthy; the script is just gone. Every later navigation in that tab: no init, cpmDashboardState=waiting, health monitor initialization_failed → stuck on the second navigation. Other tabs fine, new tabs fine, reload useless — the reported shape.

DDG already knows this hazard: UserContentController.removeInstalledUserScripts() (BSK, UserContentController.swift:261-276) uses the _removeUserScript: SPI on macOS explicitly "to avoid removal of web extension scripts". Two places bypass that guard.

macOS: Duck.ai native-storage bootstrap refresh

AIChatTabExtension.decidePolicy(for:) → refreshNativeStorageBootstrapIfNeeded (AIChatTabExtension.swift:277, 325-345) → DuckAiNativeStorageBootstrapScriptRefresher.refresh(on:staticScripts:) (DuckAiNativeStorageBootstrapScriptRefresher.swift:83-93): userContentController.removeAllUserScripts(), then re-adds only DDG's contentBlockingAssets.wkUserScripts + the bootstrap script. Runs on every cross-document navigation to a duck.ai URL in any regular tab, gated by aiChatNativeStorage = remoteReleasable(aiChat.nativeStorage), which is at 100% on macOS since 2026-05-06 (privacy-configuration commit ba4e44e03, macos-override.json:428-446, minSupportedVersion 1.187.0).

Consequence: every tab in which the user has opened duck.ai loses CPM for the rest of the session. Users who use Duck.ai in a tab and then browse in that tab, or who keep several Duck.ai tabs and reuse them, see "CPM stopped working in these tabs, new tabs are fine, reload doesn't help, Fire fixes it".

iOS: every content-blocking assets update

removeInstalledUserScripts() on iOS is the plain removeAllUserScripts() branch (UserContentController.swift:272-274), executed in contentBlockingAssets.willSet on every TDS / privacy-config / protections change (UserContentController.swift:94-107). On iOS 18.4+ with the embedded extension, every such update strips cpm.js from every open tab at once — the all-tabs variant, and it recurs several times a day. (Same for ad-blocking scriptlets.)

Reproduction (macOS, deterministic, no code changes)

1. Open tab A on a CMP site — CPM works.
2. In tab A navigate to https://duck.ai (address bar).
3. In tab A navigate to a CMP site: banner not handled; reload does not help. Health monitor: initialization_failed then stuck on the next CMP navigation in the same tab.
4. Open tab B on a CMP site: works (recovered_without_reload); back to tab A: still broken.
5. Fire → tab A works again (recovered_after_extension_reload). Verification without the marker: Safari Develop → DuckDuckGo → tab A → the "WebExtension-" content world has no cpm.js after step 2; or check webView.configuration.userContentController.userScripts for a script whose contentWorld.name == "WebExtension-<uuid>".

Diagnostic added

tab_has_extension_user_scripts = userContentController.userScripts.contains { $0.contentWorld.name == "WebExtension-<uniqueIdentifier>" } (public API). false in a stuck pixel with tab_controller_matches_context=true is this chain.

Other removeAllUserScripts() callers checked

WebView.deinit (own controller, tab dying — harmless), UserContentController.cleanUpBeforeClosing (tab closing), SuggestionsReader.tearDown (own web view), NewTabPageUserContentController (NTP-only controller), DBP/HeadlessWebView (own web views), iOS DuckPlayerWebView (own view). Only the two above touch a live browsing tab's controller.

Answer to "can one crashed/hung page affect extensions in other tabs?"

Not through WebKit: the background service-worker page gets its own WebContent process (fresh/prewarmed process at creation, _relatedWebView is nil for CPM), content-script messaging is per tab/process, and a WebContent crash only drops that process's frames from the listener map. The only cross-tab couplings are app-side: the shared WebExtensionManager state (router, controller) and the background SW's single JS thread, whose per-tab handlers are independent except the _stateQueue (which only carries dashboard state, and catches errors). The breakage reports with waiting on crashed pages are the page not committing, not CPM being affected by another tab.

RETRACTED: removeAllUserScripts() does not strip extension scripts (tested 2026-09-09)

Manual test: removeAllUserScripts() on a tab's controller leaves CPM working. Source confirms: the public API maps to WebUserContentControllerProxy::removeAllUserScripts(RemoveWebExtensions::No), which skips every script whose URL is a webkit-extension:// URL (WebUserContentControllerProxy.cpp:227-266). The Duck.ai refresher and the iOS removeInstalledUserScripts() path are therefore harmless to CPM. tab_has_extension_user_scripts stays in the diagnostics (cheap, still a valid sanity check) but is no longer expected to flip.

Tab lifecycle paths checked (all correct)

pinTab/unpinTab, moveTab(at:to:at:) between windows, drag-out moveToNewWindow, suspendTab/materialize (TabCollectionViewModel.swift:864-878, 885-897, 734-757, TabBarViewController.swift:1508-1524, TabCollection.swift:255-283) all either suppress open/close or emit the correct pair. No path found that leaves a live tab unknown to WebKit.

✅ CONFIRMED: closing a window forgets shared pinned tabs in WebKit (2026-09-10)

Reproduced manually by Alex on 2026-09-10. Scope as observed: only the pinned tab(s) lose CPM; a newly opened tab works (it goes through didOpenTab). Fits the dogfood reports: several (pinned) tabs at once, page reload does not help, Fire / extension reload fixes it, opening a new window also fixes it.

Same class, second instance: Merge All Windows (MainMenuActions.swift:1670-1695) closes the source windows via WindowsManager.closeWindows(except:) after moving their tabs; in shared-pinned mode each closing window still reports the shared pinned tabs in tabs(for:) → same didCloseTab/forgetTab on tabs that stay open in the remaining window.

General rule: any didCloseWindow while another window still displays the same Tab objects (shared pinned tabs) forgets them in WebKit. Fire's .window/.allWindows burns and pinned-mode migrations are safe because they close+reopen or replaceTab (→ didReplaceTab) every pinned tab.

Chain

1. User is in shared pinned tabs mode (TabsPreferences.pinnedTabsMode == .shared; default for existing users who had pinned tabs at migration, TabsPreferences.swift:161-165; new installs default to .separate). The same Tab objects are reported by every window: MainWindowController.tabs(for:) returns loadedPinnedTabs + loadedTabs (MainWindowController+WKWebExtensionWindow.swift:29-35).
2. User closes any window (second window, popup window, a window burned by Fire while pinned tabs exist). windowWillClose → eventsListener.didCloseWindow(self) (MainWindowController.swift:584-586).
3. WebKit WebExtensionContext::didCloseWindow → for tab in window.tabs() (live delegate query, WebExtensionWindowCocoa.mm:167-176) → didCloseTab(tab, WindowIsClosing::Yes) → tab.didClose() + forgetTab() removes the tab from m_tabMap (WebExtensionContextCocoa.mm:1312-1334, 1380-1395, 1159-1166). The shared pinned tabs are now unknown to WebKit although they are open in the remaining windows.
4. Every runtime.sendMessage from a pinned tab's content script: runtimeSendMessage → getTab(pageProxyIdentifier) → getCurrentTab searches openTabs() = m_tabMap → miss → tab not found (WebExtensionContextAPIRuntimeCocoa.mm:141-147, RELEASE_LOG_ERROR "Tab not found for message for content script message" in the app process). cpm.js's await sendMessage rejects, no init, cpmDashboardState=waiting, banner not handled. Health monitor: initialization_failed, stuck on the next navigation in any pinned tab.
5. Page reload: same (the tab object is still forgotten). Recovery: open a new window (didOpenWindow → didOpenTab for its tabs incl. pinned → getOrCreateTab re-registers), Fire (windows reopen / extension reload), extension reload (populateWindowsAndTabs()), relaunch.

Also affected: every other extension API keyed on the sender tab for those tabs (ad-blocking messaging, Dark Reader).

Reproduction (no code changes)

1. Shared pinned tabs on; pin a tab on a CMP site; confirm CPM works there.
2. Open a second window, then close it.
3. In the pinned tab navigate to a CMP site: banner not handled, reload does not help. Console.app (subsystem == "com.apple.WebKit"): Tab not found for message for content script message. Health monitor fires initialization_failed then stuck.
4. Open a new window → the pinned tab works again. Fire or Reload extension → same.

Diagnostics

Already covered: tab_known_to_webkit=false with tab_controller_matches_context=true, extension_context_errors=none. content_script_send_error=tab_not_found once the __ddgCPM marker ships.

Fix direction (not applied, per agreement — waiting for the manual repro)

App side: on didCloseWindow, tabs that remain open in another window must not be reported as closed. Options: MainWindowController.tabs(for:) excluding shared pinned tabs when the window is closing, or the events listener re-issuing didOpenTab for shared pinned tabs after didCloseWindow. WebKit side: didCloseWindow could skip tabs whose window() still resolves to an open window — worth a bug report either way.