Request for info improvement in case of website blocking due to a filter subscribed in AG adblocker

[SampeiNihira]

Issue Details

In AG MV3 the website blocking,when present, is done by the browser itself. The information to the user is very meager.

I insert an image where it is written:

"This page (web site) has been blocked by an extension".

The Log also contains very little information:

Only in the third image do I “suspect” that the website was blocked by the custom filter list I entered:

I suspect that any website block caused by a custom filter list provides the user with less information than a filter list chosen from the default filters.

Proposed solution

If the suspicion above is correct,I also propose in the custom filter lists to inform the user,in case of website blocking,with more information. Thank you for your attention.

Alternative solution

If you want to do the same test, you need to subscribe to this list of custom filters:

https://[raw.githubusercontent.com/Kees1958/W3C_annual_most_used_survey_blocklist/refs/heads/master/EU_US_MV3_most_common_ad%2Btracking_networks.txt](https://raw.githubusercontent.com/Kees1958/W3C_annual_most_used_survey_blocklist/refs/heads/master/EU_US_MV3_most_common_ad%2Btracking_networks.txt)[](url)

[krystian3w]

Looks a bug or API MV3 hardshiping:

||contentabc.com^$third-party

Cited rule shouldn't block first party opening into tab.

[maximtop]

||contentabc.com^$third-party

The rule you've specified is not the cause of the problem in MV3. Try disabling all rules, then add only ||example.org^$third-party. Go to example.org, and it should not be blocked.

@SampeiNihira please tell the version of the browser extension

[krystian3w]

But any other rule shouldn't any letter match.

The arrow on the screenshot is also not proof that there is an error in pressing the MV3 filter list "W3C blocklist" - it's simply the title of the tab that is open to the left of the locked one (normally the probability of other site visitors viewing that file is very low).

[AdamWr]

It seems that it's caused by rule like this:

||example.org^$popup,third-party

AdGuard AdBlocker 5.0.104

Screenshot


It doesn't occur if I remove third-party/popup modifier from this rule, so it looks like that only combining both modifiers cause problem.

Similar issue here - https://github.com/AdguardTeam/AdguardFilters/issues/189643

[krystian3w]

We may still see if two separate ones generate the same behavior. Then different projects can come into conflict, even though there is no native pop-up blocking API.

By the way, I wonder if the logger suggests rules from Quick Fixes (as if dynamic lists made it very difficult to predict whether a rule will be executed on the page).

[SampeiNihira]

||contentabc.com^$third-party

The rule you've specified is not the cause of the problem in MV3. Try disabling all rules, then add only ||example.org^$third-party. Go to example.org, and it should not be blocked.

@SampeiNihira please tell the version of the browser extension

The problem was opened with AG v.5.0.97. But even with AG v.5.0.104 it is the same.

My guess is that web page (contentabc.com) is should be blocked by AG Base. As it turns out from a test I did with UBO:

[krystian3w]

Let's hope it doesn't end with just fixing the behavior of rules in compression to MV3 without improving the logger to suggest what could have been executed from dynamic lists.