Proposal: allow webRequest with background.persistent: false / SW

[carlosjeurissen]

Currently the webRequest and webRequestBlocking permission require a persistent background page. This seems to be an arbitrary limitation. The proposal is to allow these APIs under a non-persistent / SW API as well.

Use cases are using this API in extension popups, or in contentScripts. The background-page doesn't need to keep running in the background for this to be useful.

Edit 2022-09-01: Firefox currently allows loading extensions with thewebRequest permission when persistent is set to false in mv2. In mv3, the persistent key is unsupported.

Related: a proposal for adding support for the webRequest API in non-persistent background pages has been added to the chrome issue tracker by @Rob--W https://bugs.chromium.org/p/chromium/issues/detail?id=447270

[Rob--W]

Could you clarify, why do you believe that this API requires a persistent background page? The use cases for extension popups/tabs sound reasonable, and I'd imagine the API to work in extensions without a background script (persistent or not).

I know that there were some technical reasons (implementation details) that prevented (blocking) webRequest from being supported in Chrome when event pages are enabled, but does this issue also extend to other browsers? Is this issue a bug report about Chrome, or is it broader than that?

[carlosjeurissen]

@Rob--W Currently I'm not aware of any reasoning behind this. I can only speculate on that. Potentially it was seen that webRequest listeners would mostly make sense when they are constantly there. But that is not necessarily true.

[Rob--W]

..., but does this issue also extend to other browsers? Is this issue a bug report about Chrome, or is it broader than that?

@carlosjeurissen ^

[carlosjeurissen]

@Rob--W Just tested in Safari on macOS and turns out just like in Google Chrome one cannot use the webRequest API with a non-persistent background page.

As for Mozilla Firefox, not sure what the current behaviour is with the WebRequest API and the limited event page (#134)

[Rob--W]

This topic came up during today's WECG meeting. Relevant part from the meeting notes (currently pending review, will be merged and published at https://github.com/w3c/webextensions/blob/main/_minutes/2022-02-03-wecg.md)

• [timothy] webRequest is not supported in non-persistent background pages in Safari, because we looked at Chrome, which didn't support it either.

[tophf]

Chrome didn't support webRequest in an event page because it wasn't exactly trivial to support waking up the event page and it would cause frequent restarts of the event page as such events tend to happen frequently.

The support for SW, which are conceptually the same as event pages, is being implemented currently in https://crbug.com/1024211, so there's no reason it can't be made to work with an event page. Note that webRequest + webRequestBlocking as optional permissions always worked in an event page while it was running, it just didn't wake up.

[carlosjeurissen]

@tophf Thanks for clarifying! My use case for the webRequest API is only in non-background contexts. In which case it's a pity a permanent background page has to run for this to work.

[tophf]

But you don't need the background script at all if you use webRequest only in a visible page.

[carlosjeurissen]

@tophf correct! Yet Google Chrome doesn't allow loading an extension with the webRequest permission and a non-persistent background page at this moment.

[tophf]

As I mentioned in my comment, all you need is to use optional permissions and it'll work with a non-persistent background script.

[carlosjeurissen]

Firefox currently allows loading extensions with thewebRequest permission when persistent is set to false in mv2. In mv3, the persistent key is unsupported.

Related: a proposal for adding support for the webRequest API in non-persistent background pages has been added to the chrome issue tracker by @Rob--W https://bugs.chromium.org/p/chromium/issues/detail?id=447270