DNR clarification

[Browser Extenstion]

We have a rule for declarativeNetRequest (which can also have "type": "redirect"):
{
"id": 1,
"action": {
"type": "block"
},
"condition": {
"urlFilter": "||example.com^",
"resourceTypes":["main_frame"]
}
}

Let's say we have an onBeforeRequest listener, and for our domain,
request.documentLifecycle --> PRERENDER.

Am I correct in understanding that in this case, the declarativeNetRequest rule will not work until request.documentLifecycle --> ACTIVE?

[Oliver Dunk]

Hi,

We don't have much documentation around the interaction of Declarative Net Request and pre-rendering, but I would expect the rules to still apply even in the "prerender" stage.

Were you just curious, or are you seeing something specific?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/84f7ef92-a608-4ba0-a046-c30c38743028n%40chromium.org.

[Browser Extenstion]

I see a different situation. It's easier to illustrate with a redirect example.
Here is the DNR rule:

{
"id": 1,
"action": {
"type": "redirect",
"redirect": {
"url":"https://www.w3.org/"

}
},
"condition": {
"urlFilter": "||example.com^",
"resourceTypes":["main_frame"]
}
}

Here is the result of loading the domain with the "prerender" status:

{
    "documentLifecycle": "prerender",
    "frameId": 58,
    "frameType": "outermost_frame",
    "method": "GET",
    "parentFrameId": -1,
    "requestId": "1896",
    "tabId": 1519722200,
    "timeStamp": 1739444228733.015,
    "type": "main_frame",
    "url": "https://example.com/"
}

The redirect does not occur.

First, I would like to clarify whether this is the intended behavior.
Second, I want to understand why the redirect does not happen:

• Does DNR not work with prerender?
• Does DNR not redirect because frameId is not equal to 0?

[Oliver Dunk]

When you share the "result" of prerendering, is that a log from the webRequest API? Which event are you listening to?

The end result for the user should be the same for a page affected by a DNR redirect rule, regardless of if prerendering takes place. The frame ID should be 0 as expected.

All of this said, exactly how that looks throughout the request is less well defined. I wouldn't be surprised if you saw an early event like webRequest.onBeforeRequest that was then subsequently redirected by a DNR rule.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Browser Extenstion]

Yes, I am using the chrome.onBeforeRequest listener.
If the site only reaches the prerender status (e.g., when hovering over an icon/bookmark or right-clicking on a bookmark) and does not transition to active, the DNR rules do not trigger.

P.S. In this case, frameId is not 0 (as shown in my previous message).

[woxxom]

Logically, it should work, assuming your extension has host_permissions for both the original site and the target site, which is not explicitly mentioned in the documentation by the way and thus often confuses developers. Otherwise DNR may have a bug e.g. maybe resource type is "other" in chrome.declarativeNetRequest.onRuleMatchedDebug.

[Oliver Dunk]

P.S. In this case, frameId is not 0 (as shown in my previous message).

Apologies, I missed this. Looking at the changes we made to support prerendering it seems like this is expected: https://developer.chrome.com/blog/extension-instantnav#outermost-frame. However, I would still expect us to apply redirect rules and treat this as being the "main_frame" resource type.

If you're not seeing that, could you open a bug at https://crbug.com/ with steps to reproduce?

Logically, it should work, assuming your extension has host_permissions for both the original site and the target site

As far as I know there aren't any cases where we require host permissions to the destination of a redirect. Do you mean that you need host permissions for both the initiator and request URL perhaps? It does look like we could improve the documentation on that.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[woxxom]

I made a mistake, the target host permission is not required, but indeed the documentation could elaborate on host-permissions when redirecting:

1. in the very beginning where permissions are mentioned,
2. in every example for direction with an emphasis on the reason e.g. "Requires host_permissions for the source URL *://*.example.com
3. in Action -> "redirect" short description.