declarativeNetRequest two extensions priority

[Browser Extenstion]

declarativeNetRequest two extensions priority

Let's say there are two extensions that use declarativeNetRequest permission.

The first one has rule:
{
    "id": 1,
    "action": {
        "type": "block"
    },
    "condition": {
        "urlFilter": "||example.com^",
        "resourceTypes": [
            "main_frame"
        ]
    }
}

The second one has rule:
{
    "id": 1,
    "action": {
        "type": "allow"
    },
    "condition": {
        "urlFilter": "||example.com^",
        "resourceTypes": [
            "main_frame"
        ]
    },
    "priority": 1
}

When two extensions are enabled, the domain is blocked despite the fact that the second extension has higher priority.
Is any option to change this behavior?

[wOxxOm]

This is working correctly because the default "priority" is 1, so both rules have the same priority, and "block" is considered before "allow". To increase the priority you should increase the number.

[Browser Extenstion]

Sorry, my mistake.
The priority of second extension is 2 and it is still blocked by the first extension.

[wOxxOm]

If you reloaded the extension after editing its rules, it looks like a bug in this API.

[Browser Extenstion]

From the https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#matching-algorithm:

Before the request is sent, each extension is queried for an action to take. The following actions are considered at this stage:

• Actions which block requests of type block
• Actions which redirect requests of type redirect or upgradeScheme
• Actions which allow requests of type allow or allowAllRequests

If more than one extension returns an action, the extension whose action type comes first in the list above gets priority. If more than one extension returns an action with the same priority (position in the list), the most recently installed extension gets priority.

I don't quite understand this sentence.
If we have more than one extension so the priority does not matter? If type on one of the extension is "block" so the request will be blocked even we have "allow" type in other extension with higher priority?

If so, then this is not a bug, but expected behavior. But in my opinion it shouldn't work like that.

[wOxxOm]

I assumed that sentence is very poorly written because this behavior wouldn't make any sense - how else would we be able to override a blocking rule?

[Browser Extenstion]

I opened a new bug: https://crbug.com/1405617

[Daniel Marino]

I think this is working correctly, and the documentation is a bit confusing, but accurate. The term priority is overloaded in so many ways here. :-)

In the matching algorithm documentation mentioned above, the priority of the DNR rule does not figure at all. This makes sense. DNR rule priority is only relative among rules within an extension. It wouldn't make sense to have arbitrary rule priorities interact across extensions (possibly written by different developers). The documentation attempts to clarify with its parenthetical "priority (position in the list)". That is to say: BLOCK trumps REDIRECT which trumps ALLOW. Blocks always wins.

So, what the documentation says is that if ANY extension returns action BLOCK, then the connection will be blocked. This makes sense. It's how things worked in MV2 as well.  If an extension requested that a connection be blocked when returning from a webRequestBlocking onBeforeSendHeaders, then the connection was blocked, period. Another extension cannot revive the connection.

However, if two extensions both request that the same request is redirected to two different URLs, then the more recently installed extension wins.

[Browser Extenstion]

Let's assume that you are using Google Analytics in your extension.
This is a necessary condition for your extension to work correctly.
Another extension is blocking access to this domain.

What options do we have in this case?

[Robbi]

I'm not a frequent user of the DNR API
But what @Daniel says seems correct to me.
Priority is a number that makes sense only within extension.
If it were not so then why not use big long integer numbers and "win over all competitors"?

It's a bit like having two installed extensions that want to change the "new tab"; the last extension installed wins over any other similar ones.
In the example of Google  Analytics, I would suggest setting that domain among those allowed (in case that our extension is the last installed extension)

and in any case test the domain accessibility with a preventive fetch.

If the fetch is blocked, a warning message will be prompt to advice user about a possible installed extension which affects the correct functioning of our extension.

[wOxxOm]

Just because it worked like this in MV2 doesn't mean the same should be propagated into the future if it's confusing or wrong. To me the naturally expected outcome is that the most recent extension should win regardless of the type of the action or maybe Chrome could expose some UI where the user can customize the order of declarativeNetRequest extensions or at least choose one extension that always wins.