In webRequest, extensions may only modify requests when they have the host permissions to access to the request URL and to access to the document URL, if any. This is an allowlist-based approach.
In DNR, the
declarativeNetRequest permission is meant to offer request blocking functionality without host permission checks. Anything more than just blocking (redirect / modifyHeaders) requires host permissions. DNR currently uses a deny-based approach: Consistent with webRequest, DNR already ignores system requests and requests to restricted domains. And with bug 1810753, requests from other extensions are blocked too. But e.g. about:-URLs are not explicitly rejected.
As a result, if I open a new tab (
about:newtab) after installing a DNR extension with rules, an attempt to evaluate the DNR rules occurs. Because
about:newtab is unexpected, an error is thrown when the unexpected URL is encountered in
#domainFromURI for the initiatorURI (triggeringPrincipal):
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.host]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/ExtensionDNR.sys.mjs :: #domainFromURI :: line 1160" data: no]
Instead of this accidental implementation detail, we should just filter out URIs whose schemes are certainly not known to be available to extensions. Note: opaque initiators are out of scope here (handled in bug 1798225).