feat: observational chrome.webRequest support

[dep]

What

Implements observational chrome.webRequest support: a main-process WebRequestAPI bridging Electron's session.webRequest to extension contexts, and a full preload surface replacing the previous onHeadersReceived-only stub (which registered listeners that never fired).

Why

MV3 extensions that observe network activity (password managers, privacy tools) currently crash at startup in Electron-based browsers: Electron registers the webRequest schema but the API is non-functional in extension contexts, so chrome.webRequest.onBeforeRequest is undefined, the service worker throws, and MV3 worker registration fails outright. Context and root-cause analysis in electron/electron#52265 — notably, even on Electron main (where the Electron 43 bindings-pak regression is fixed), webRequest events are never dispatched to MV3 service workers; MV2 background pages work. This PR makes the polyfill cover the gap for both.

Verified end-to-end on Electron 43: an MV3 extension whose worker calls chrome.webRequest.onBeforeRequest.addListener(...) at top level — previously an instant crash ("Service worker registration failed. Status code: 15") — now registers and receives events for page loads.

Design notes

• Observational only. Electron's blocking-capable events have their callback resolved with {} immediately, before fan-out. 'blocking'/'extraHeaders' in extraInfoSpec are silently ignored, and listener return values have no effect. (MV3 Chrome itself restricts blocking webRequest to policy installs, so observational is the meaningful MV3 surface.)
• Lazy attach/detach. Because a single session.webRequest listener disables Chromium's native extension webRequest and declarativeNetRequest enforcement for new URLLoaderFactories (Electron's exclusivity rule), WebRequestAPI attaches a session listener per event only on the 0→1 extension-listener transition and detaches on the last removal. Sessions/events with no webRequest listeners are untouched, so dNR-only extensions (e.g. uBO Lite dynamic rules) keep native enforcement. Implemented via new listener-added/listener-removed events on ExtensionRouter.
• Per-extension fan-out with permission gating. Events are sent per extension via router.sendEvent (never broadcast), gated on the webRequest manifest permission plus host-pattern matching (host_permissions MV3 / permissions MV2, <all_urls>), so URLs don't leak to extensions without access. Service-worker delivery reuses the router's existing startWorkerForScope wake-up.
• Details mapping. requestId, Chrome resource-type names (xhr → xmlhttprequest, etc.), headers as [{name, value}], requestBody.raw from uploadData, statusCode/statusLine/fromCache/ip/redirectUrl/error where Electron provides them; tabId is -1 for untracked webContents; frameId/parentFrameId approximated from frameTreeNodeId (consistent with web-navigation.ts).
• Preload applies RequestFilter (urls via Chrome match-pattern semantics, types, tabId) and strips requestHeaders/responseHeaders/requestBody unless requested via extraInfoSpec. handlerBehaviorChanged is an async no-op. onAuthRequired is registrable but never emits (no session.webRequest equivalent).

Known limitations vs Chrome

• No blocking/modification; no onAuthRequired events.
• While any extension listens to a webRequest event, native extension webRequest and dNR enforcement are disabled for new loader factories in that session (Electron exclusivity; lazy attach minimizes exposure).
• No initiator, documentId, documentLifecycle, frameType; no formData parsing; filter.windowId unsupported; runtime-granted optional host permissions not consulted.

Tests

New spec/chrome-webRequest-spec.ts + spec/fixtures/chrome-webRequest/: 6 specs covering event details (url/method/type/tabId/frameId/requestId), subresource typing, URL filtering, extraInfoSpec header gating, detach-on-removal, and lazy attach (no session listeners without extension listeners). Full package suite: 70 passing, 0 failing (2 pre-existing pending). build (tsc + esbuild) clean.

🤖 Generated with Claude Code

[dep]

Pushed a follow-up commit after validating against a real-world extension (NordPass, MV3, worker-driven action button):

• Native browser namespace: Chromium now exposes a native browser global in extension contexts as a distinct object from chrome. Extensions resolving globalThis.browser || globalThis.chrome saw only the unpatched native APIs (memberless webRequest, etc.). The preload now injects the same API objects into both namespaces. browser is intentionally left unfrozen — Chromium leaves it configurable, and extensions that wrap it in a Proxy returning substitute objects from get() (NordPass does) would hit the proxy invariant for frozen data properties.
• ChromeSetting stubs: get/set/clear previously returned undefined, crashing promise-style callers (privacy.services.passwordSavingEnabled.get({}).then(...)). They now return Chrome-shaped results ({ value, levelOfControl: 'not_controllable' }) as promises or via callback.

With these plus the webRequest backend, NordPass's MV3 service worker goes from crashing at startup to fully initializing — registering action.onClicked and calling action.setPopup — on Electron 43.

[Anutim]

This breaks adblockers somewhat unfortunately, tested on Electron 41 and 43 against ads like Adchoice (with Adguard/uBlock/uBlock Lite).
In my experience this happens in general with Electron when you use the webRequest events.

The website I'm testing with for issues is spriters-resource.com, Adchoice is shoved in everywhere there.

[Anutim]

I should clarify that I did try with uBlock Lite in Electron 43 with and without the PR (and it successfully blocking the above mentioned site's ads only without the PR), since you mentioned that adblocker in your first post.