webRequest docs missing MV3 deprecation warning for blocking API

561 views
Skip to first unread message

Alesandro Ortiz

unread,
Aug 16, 2022, 9:26:58 PM8/16/22
to Chromium Extensions
Hello,

The docs for webRequest are silent on whether the API is partially or completely deprecated in MV3.

My understanding is the webRequest *blocking* API is unavailable in MV3 for user-installed extensions, but the non-blocking APIs remain available in MV3 for all. However, the docs for webRequest does not say anything about deprecation or specific manifest version support like most other pages do.

1. Is the webRequest non-blocking API still available in MV3?
2. Can someone update the docs to clarify what is and isn't deprecated within webRequest?

I started implementing webRequest in an MV2 extension before I remembered that some APIs with the word "request" in their name were deprecated in MV3. Even then it took a lot of time to find any info about webRequest deprecation, and I'm still somewhat uncertain now.


The MV3 intro migration page says the following:
Can Manifest V3 extensions use blocking Web Request?

The blocking version of the Web Request API exists in Manifest V3, but it can only be used by extensions that are force-installed using Chrome's enterprise policies: ExtensionSettingsExtensionInstallForcelist.

Extensions meant to be used by the general public must now use Declarative Net Request for network request modification. Here 'used by the general public' means any extension published to the Chrome Web Store except those deployed to a given domain or to trusted testers.

The migration checklist also mentions:

Are you currently using the blocking version of chrome.webRequest?
This API is replaced by declarativeNetRequest in Manifest V3.

This only applies to user-installed extensions; force installed extensions (extensions distributed using ExtensionInstallForcelist). These extensions — typically used in an enterprise setting — can still use the blocking version of chrome.webRequest.


Regards,
Alesandro

Alesandro Ortiz

unread,
Aug 16, 2022, 10:30:41 PM8/16/22
to Chromium Extensions, Alesandro Ortiz
Hello,

While filing an issue for something else, I found a few related issues in the developer docs repo:

Issue 1263's description from a Chrome team member answers my original question:
"The text should clearly indicate that non-force installed extensions can use webRequest to observe network requests, but only force-installed Manifest V3 extensions can use the webRequestBlocking permission to modify network requests."

Hope the docs are updated soon!

Regards,
Alesandro

wOxxOm

unread,
Aug 17, 2022, 10:24:18 AM8/17/22
to Chromium Extensions, ales...@alesandroortiz.com
Non-blocking webRequest remains fully functional, it's not deprecated as can be inferred even from the quoted fragments, but I agree it should be stated explicitly and unequivocally.

Mike-O

unread,
Aug 17, 2022, 11:15:56 PM8/17/22
to Chromium Extensions, wOxxOm, ales...@alesandroortiz.com
Yes, I am finding that chrome.declarativeNetRequest.getMatchedRules is not reliable due to some of the restrictions it has and isn't giving me an accurate count on the rules that match after a certain amount of time has passed. My rules are merely redirect rules, so I added chrome.webRequest.onBeforeRedirect.addListener to my service worker in a non-blocking way -- and sure enough -- I can now identify a proper count of items I redirected in code.

The docs have this section:


...and it states:

The blocking version of the Web Request API exists in Manifest V3, but it can only be used by extensions that are force-installed using Chrome's enterprise policies: ExtensionSettings, ExtensionInstallForcelist.

Extensions meant to be used by the general public must now use Declarative Net Request for network request modification. Here 'used by the general public' means any extension published to the Chrome Web Store except those deployed to a given domain or to trusted testers.

Since I'm not calling chrome.webRequest.onBeforeRedirect.addListener in blocking mode, then the first paragraph seems to not apply to my code design. Since I'm not doing network request modification via chrome.webRequest.onBeforeRedirect.addListener, but merely using it for inspection, then the second paragraph doesn't seem to apply to my code design either. I am doing network request modification using chrome.declarativeNetRequest, however.

Can we anyone from the official Google team in charge of this respond to confirm what wOxxOm has stated and what I have found as well?

Hao Nguyen

unread,
Sep 22, 2022, 9:43:13 AM9/22/22
to Chromium Extensions, Mike-O, wOxxOm, ales...@alesandroortiz.com
From https://bugs.chromium.org/p/chromium/issues/detail?id=1338871#c6, it sounds like someone on the Chromium team is hinting that webRequest will be removed in the future as well. My guess is that the Chromium team will someday decide to remove it on a whim, and again no amount of protest from developers will amount to anything.
Reply all
Reply to author
Forward
0 new messages