Fire webRequest events for declarativeNetRequest-blocked loads

Component: WebKit Web Extensions | 162e023

Source/WebCore/contentextensions/ContentRuleListBlockedLoadInfo.h

#if ENABLE(CONTENT_EXTENSIONS)
 
namespace WebCore {
 
struct ContentRuleListBlockedLoadInfo {
    FrameIdentifier frameID;
    URL url;
    String httpMethod;
    OptionSet<ContentExtensions::ResourceType> resourceType;
    Vector<String> blockingContentRuleListIdentifiers;
};
 
}

declarativeNetRequest (dNR) block rules are compiled into a content rule list and enforced entirely inside the WebProcess by the content-extension engine, before a request would ever reach the NetworkProcess — which is where webRequest events are normally generated. Blocked loads were therefore invisible to extensions listening for webRequest events.

This commit adds a ChromeClient::contentRuleListDidBlockLoad hook at the enforcement site, packaging load metadata (frame identifier, URL, method, resource type, and the identifiers of the rule lists that blocked it) into the new ContentRuleListBlockedLoadInfo struct and sending it WebProcess→UIProcess. The UIProcess resolves the owning WebExtensionContext by matching blockingContentRuleListIdentifiers, then routes the event back down to that extension's WebProcess proxy to fire webRequest.onBeforeRequest followed by onErrorOccurred, matching Chrome and Firefox behaviour. A hardcoded net::ERR_ABORTED string is replaced with the load's real localized error description.

Significance

This closes an observability gap where dNR-blocked loads previously produced no webRequest events at all. Extensions that reconcile their own block rules against observed traffic were silently missing every enforcement event they themselves caused.

Audit directions

The forward-facing pattern is a fabricated event routed to a recipient chosen by an identifier that a lower-privilege process supplied. Narrow: check whether WebExtensionController's routing by blockingContentRuleListIdentifiers strictly scopes the event to the extension that actually owns the matching rule list — a compromised or confused WebProcess sending identifiers it does not own would otherwise trigger observer callbacks inside a different extension's context, which is a cross-extension confused-deputy. Wider: the FrameIdentifier crossing this new boundary is the second half of the same question — audit parentFrameIDForBlockedLoad in WebChromeClient.cpp for frames torn down between the block and the report, since a stale or mismatched identifier arriving at a UIProcess frame lookup is a source of confusion in every downstream consumer. Apply the same two questions to the other WebProcess→UIProcess→WebProcess round-trips in the extension layer, where an identifier chosen renderer-side selects the recipient of a message the recipient will treat as authoritative. Widest: whenever a privileged router picks a destination from an untrusted field, the check to look for is whether ownership of that identifier is verified against what the sending process was already known to hold.