Ad Block filter universal syntax broken

[JakobJingleheimer]

Description

Until recently, excluding a domain prefix to a filter would cause that filter to be applied universally to all sites. For instance ##.foo would block any element with a css classname of "foo" on any site. This has stopped working.

Non-universal syntax still works (prepending the filter with a domain).

Steps to Reproduce

1. Manually add a custom filter via brave://adblock/ such as ##.foo
2. Visit a site with an element with that class
3. Element is not blocked

Actual result:

The custom filter is ignored

Expected result:

The custom filter is applied

Reproduces how often:

Easily reproduced

Brave version (brave://version info)

Brave: V1.26.77 (it was broken in the previous version too)
OS: macOS 11.4 (ARM & Intel)

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes
• Can you reproduce this issue with the beta channel? Maybe
• Can you reproduce this issue with the nightly channel? Maybe

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? N/A
• Does the issue resolve itself when disabling Brave Rewards? N/A
• Is the issue reproducible on the latest version of Chrome? N/A

Miscellaneous Information:

N/A

[ryanbr]

Can confirm. Add the following github.com##.btn-primary vs ##.btn-primary (which hides the green button on https://github.com/brave/brave-browser/issues github.com##.btn-primary works fine, just not ##.btn-primary.

cc: @antonok-edm

[JakobJingleheimer]

Nudge. There have been multiple releases since this was reported a couple months ago. This was a great feature. Any chance of a fix soon?

[antonok-edm]

Just looked into this. GitHub appears to have a generichide rule, which means that any global CSS rules should not be applied - this is working "as intended."

https://github.com/easylist/easylist/blob/36cd41e27b9bd46950f783e3ad0ae2f3d50fde52/easylist/easylist_allowlist.txt#L255

@ryanbr do you know what the intended way of reverting a generichide rule in another list is? Is badfilter the only option? If so, I don't think there's an easy way to prevent this behavior until later planned work where the adblock engines (default, regional, custom, etc.) will be combined into a single engine.

[JakobJingleheimer]

I'm not sure what this means, but the issue is not specific to GitHub (it affects all sites); GitHub was merely a proof of reproduction.

[ryanbr]

@JakobJingleheimer adding github.com##.foo rather than ##.foo would get around this. (specific to github.com in this case)
@antonok-edm Was added to prevent unintended cosmetics being used on Github in error. This was only recently implemented, the filter is quite new.

[ryanbr]

As a test try https://www.bleepingcomputer.com/ add ##.bc_logo into brave://adblock (which should hide the logo, top left)

[antonok-edm]

@JakobJingleheimer you're right, it does look like it happens on some other sites too - I think my changes in https://github.com/brave/brave-core/pull/9995/files#diff-e445b72318a833eb8c97e6945d9a13b3efc44710de6449146579c48da455711b might help as well.

[antonok-edm]

I'll consider this fixed by brave/brave-core#9995, but @JakobJingleheimer please let me know if there are still any problems with it in 1.31.x

[JakobJingleheimer]

@antonok-edm thank you! I shall check when it's released. I just checked, and it seems I have the latest release of Brave (v1.29.79). I see in this repo though, that there are more recent releases, which I assume are Nightly? Or does this repo's version not correspond to Brave's version numbering?

[antonok-edm]

Yes, at the moment 1.31.x is Nightly and 1.30.x is Beta. Our release schedule is on the wiki if you're curious.

[JakobJingleheimer]

@antonok-edm 1.31 is out but sadly this not fixed :(

[antonok-edm]

@JakobJingleheimer could you post an example of a filter/site combination which does not work? It seems okay on my end.

[JakobJingleheimer]

1. go to brave://adblock
2. Set the Custom Filters textarea to just ###cookiebanner (and nothing else)
3. Go to https://www.circleci.com
4. Obnoxious cookiebanner is displayed (the element containing it is a div with id cookiebanner)

[antonok-edm]

Had to use an EU VPN to see the cookiebanner in the first place, but now I see that it is indeed not hidden in standard Shields mode. Will work on a fix for that as well, since that's still not intended. In the meantime, you should be able to fix it by setting Trackers & ads blocked (aggressive) either per-site in the Shields panel or globally in brave://settings/shields.

Edit: filed #19085

[JakobJingleheimer]

Thank you!