Can I use Chrome declarativeNetRequest to completely replace Chrome webRequest?

user_5210240 0
Viewed 5776

I found chrome.declarativeNetRequest only supports static rules, What I want is to call some custom methods before actions like redirect/request. I haven't found a solution so far. I'm not sure if I can still do this under the Manifest V3.

There are two usecases for my extension.

  1. Before the redirect, I need to execute custom method.
    chrome.webRequest.onBeforeRequest.addListener(
        function(requestDetails) {
            //
            // I can get id from requestDetails.url,
            // then do some custom business logic.
            //
            custom_function(requestDetails.url);
            return {redirectUrl:"javascript:"};
        },
        {urls: [ "url_pattern?id=*" ]},
        ["blocking"]
    );
  1. Before some request, I want add/modify requestHeaders according to the user's browser.
chrome.webRequest.onBeforeSendHeaders.addListener(
    function (details) {
        details.requestHeaders.push({
            "name": "User-Agent",
            "value": navigator.userAgent + "version_1.0.0"
        });
        return {requestHeaders: details.requestHeaders};
    },
    {
        urls: ["*://url_pattern"],
        types: ["xmlhttprequest"]
    },
    ["blocking", "requestHeaders"]
);

@wOxxOm Thank you very much for your patient answer !
I prefer to spinner.html. But I have another problem.

I can't set the regexSubstitution to the extension address,
I can use the extensionPath, but the corresponding capture groups doesn't work here.

"regexFilter": "google.com*"

The following are all incorrect:

can't use the corresponding capture groups.
"extensionPath": "/spinner.html?url=\\0"

can't use the extension's address.
"regexSubstitution": "spinner.html?url=\\0"

Is my configuration incorrect?

google-chrome-extension
1 Answers

  • Adding/deleting headers can only accept static values and it's shown in the official example.

  • Conditionally adding/deleting/modifying headers based on response headers is tracked in https://crbug.com/1141166.

  • Nontrivial transformations that exceed the functionality of the actions listed in the documentation naturally cannot be re-implemented.

  • When https://crbug.com/1262147 is fixed we will be able to define a declarativeNetRequest rule to redirect to a page inside your extension via regexSubstitution or extensionPath and append the original URL as a parameter. This page will act as an interstitial, it will display some kind of UI or a simple progress spinner, process the URL parameters, and redirect the current tab to another URL.

    In many cases this approach would introduce flicker and unnecessary visual fuss while the interstitial is displayed shortly, thus frustrating users who will likely abandon using such extensions altogether. Chromium team members who work on extensions seem to think this obscene workaround is acceptable so it's likely they'll roll with it, see also https://crbug.com/1013582.

  • Use the observational webRequest (without 'blocking' parameter) and chrome.tabs.update to redirect the tab. The downside is that the original request will be sent to the remote server. And this approach obviously won't work for iframes, to redirect those you'll have to inject/declare a content script, to which your webRequest listener would send a message with a frameId parameter.

  • Keep a visible tab with an html page from your extension, and use the blocking chrome.webRequest inside its scripts. It's a terrible UX, of course, even though endorsed by the Chromium's extensions team, with many extensions using this kludge the user's browsers will have to keep a lot of such tabs open.

P.S. The blocking webRequest will be still available for force-installed extensions via policies, but it's not something most users would be willing to use.

user_39598750
Related