Skip to content
This repository has been archived by the owner on Jul 12, 2024. It is now read-only.

Is main_frame being blocked by default if excludedResourceTypes is used for a rule? #38

Open
balwantgill opened this issue Apr 6, 2023 · 0 comments
Assignees
Labels
Priority: P4 Question Further information is requested

Comments

@balwantgill
Copy link

balwantgill commented Apr 6, 2023

Is main_frame being blocked by default if excludedResourceTypes is used for a rule?

Is this intended behavior?
It says on https://adguard.com/kb/general/ad-filtering/create-own-filters/#document-modifier that AdGuard doesn't block main frame by default unless $document is present in a rule

"By default, AdGuard does not block the requests that are loaded in the browser tab (e.g. "main frame bypass"). The idea is not to prevent pages from loading as the user clearly indicated that they want this page to be loaded. However, if the $document modifier is specified explicitly, AdGuard does not use that logic and prevents the page load. Instead, it responds with a "blocking page".

But I think because excludedResourceTypes from declarativeNetRequest is blocking all resource types that aren't explicitly stated, this also blocks main_frame too?

Note that if there's no resourceTypes or excludedResourceTypes in a rule, declarativeNetRequest will just block everything except for main_frame

"List of resource types which the rule won't match. Only one of resourceTypes and excludedResourceTypes should be specified. If neither of them is specified, all resource types except "main_frame" are blocked."

See excludedResourceTypes on https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#type-RuleCondition

But it seems like if you specify excludedResouceTypes, it'll block main_frame too unless you explicitly tell it not to?

Should main_frame be added to the excludedResourceTypes too?

A few examples of this (the last one is the way I think the intended functionality is for rules in the main AdGuard extension):

The following example rule will also block main_frame for an example domain (google.com) unless it's explicitly stated:

{
	"id": 1,
	"action": {
		"type": "block"
	},
	"condition": {
		"urlFilter": "||google.com^",
		"excludedResourceTypes": [
			"script",
			"image",
			"media"
		],
		"isUrlFilterCaseSensitive": false
	}
}

If the rule is then changed to add main_frame to the excludedResourceTypes this will let it load the page along with script, image, and media but block the other resource types:

{
	"id": 1,
	"action": {
		"type": "block"
	},
	"condition": {
		"urlFilter": "||google.com^",
		"excludedResourceTypes": [
			"script",
			"image",
			"media",
			"main_frame"
		],
		"isUrlFilterCaseSensitive": false
	}
}

If you remove the other excluded resource types it will just load the page without script, image, media, and the other resource types:

{
	"id": 1,
	"action": {
		"type": "block"
	},
	"condition": {
		"urlFilter": "||google.com^",
		"excludedResourceTypes": [
			"main_frame"
		],
		"isUrlFilterCaseSensitive": false
	}
}

If image and main_frame is then added to excludedResourceTypes it will block all resourceTypes except for image and main_frame:

{
	"id": 1,
	"action": {
		"type": "block"
	},
	"condition": {
		"urlFilter": "||google.com^",
		"excludedResourceTypes": [
			"image",
			"main_frame"
		],
		"isUrlFilterCaseSensitive": false
	}
}

So for the last example, if a rule in the AdGuard filter list was defined to exclude image resource types from being blocked (~image), it also wouldn't block main_frame.

I think the last example would be the intended functionality as it works in the main AdGuard extension, because main frame is not blocked by default in the main AdGuard extension unless the rule says to block this (with $document).
For MV3 rules, would adding main_frame also then be needed to be used for rules that use excludedResourceTypes by default?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Priority: P4 Question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants