Thank you very much, woxxom, for your always knowledgeable answers.

Can you predict that navigation will occur from the content script and wake up the background script by sending a message? This will require you to run a content script in arguably every web page and frame, so it will consume megabytes for users with many tabs which is much more wasteful than keeping the background script alive.

Hmm, that gives me an idea. In fact, clicks on such intercepted URLs only occur on pages of the same domain, and I already insert a content script into all pages of such domains for other reasons. So I could simply send heartbeat messages from the content scripts to the background script to keep it alive only when pages from such domains are open, and the background script could then go inactive when no such pages are open. In this case, I can register the listener asynchronously only for the relevant URLs. That should work and be a reasonable compromise, right?

I see a similar use case in WECG suggestion #908, so it would make sense to open an issue there

I don't think it's quite the same issue. It addresses other issues that I also have/had, such as that there are no DNR events in no-dev mode, which I think is another major shortcoming, or that I didn't want the ERR_BLOCKED_BY_CLIENT error page to be displayed when a request is blocked. The browser should just do nothing.

I ended up using the redirect rule to redirect requests to a public 204 ‘no content’ endpoint for the ‘block’ and listening for the onHeadersReceived event for that redirect URL to be notified when a ‘block’ occurred. It’s again a hack, but it works...

but many important use cases have been crippled or completely destroyed for years going forward until a better alternative is devised in the API, if ever.

Hope dies last...