Can't access comments at InstaPundit with Brave

Comments cannot be accessed with Brave.
Even turning shields off doesn’t work.
With Pale Moon I can get into comments with extension Adblock turned off.

Having the same issue. For me if shields are down it works fine but if any of the add blocking is on the comments are invisible. They do actually seem to load but then they immediately disappear.

Obviously it is an adblocker issue. @@||$ghide in brave://adblock would fix it

To explain this, Cosmetic rules are done in two ways, generic or specific to a website. Brave can apply both of them, but can’t whitelist them per website, so all the generic ghide = generichide will remove them all.

There is another deep subject, Brave adblocker has multiple engines, it is better than a year ago, but still we have two different engines, so Default lists are technically separated from Custom filters/rules and regional lists.

So in theory, there is a workaround about this, doing the exception with the :style() action operator.

so these two rules

could be done with: block !important;) block !important;)

and it would work, but because Default lists are in a different engine and merged, these Style can’t never override the generic cosmetics being applied to instapundit.

If you load Brave default lists as Custom lists, and disable the default lists and try these rules, it will work.

Anyway, the only workaround is to remove all generic cosmetics, which means some spaces and ads might appear, unless Brave targets the ads specifically for the website, you know, remove generic and add specific cosmetics for the website.

Easy fix.

I don’t know why it hasn’t been fixed in 5 days, but there is the solution until and if it gets fixed by Brave team.

Forgive me but this is my first time delving into the intricacies of Brave’s adblock. Can you’re explain how to do that in more detail or point me at a tutorial? And, is it possible to do that on iOS/iPadOS?

iOS doesn’t allow custom Adblock rules, so not possible, this is because iOS versions of Brave are limited to webkit, the only allowed engine by Apple in their app store.

For Android and Desktop, they both use the real Chromium and share the same features in the adblocking, so you just go to brave://adblock and paste @@||$ghide where it says custom filters and done, it will work until this is fixed in the Default lists.

I guess @fanboynz is the only one who can fix this in the default lists, so iOS users don’t have to turn the adblocker off.

Perfect worked great on desktop. Hoping for iOS fix soon.
Thank you!

As for the first part of your question, I think you are asking for a walk-through of how to do it. Here is what I did:

Clck on the hamburger (overflow) button in the top, right corner of the window.

Click “settings.”

Click “Shields.”

Click “Content Filtering.”

Copy: block !important;) block !important;)

Paste that in the “Create Custom Filters” box at the bottom of that screen.

Click “Save Changes.”

I’m no expert, so there are probably better ways, but that worked for me. And thank you to Emi for the fix.

No, that will not work.
I explained why, Default list are in a different Adblock Engine than Custom filters. that only works if you have all the lists in the same Engine, same with $badfilter

That means it will only work for regional lists or custom lists if you add like a 3p list you can’t modify.

You have to use @@||$ghide to remove all generic cosmetic rules from the page.

They are adding the comments in the .ads or some div, so they need to be unhidden, but since Brave doesn’t support a cosmetic exception for specific rules and ignores what uBlock has, $ghide is the only solution.

Okay, well, I freely admit that you definitely know better than I, but I do know that what I wrote does work for me. Thanks again for you help.

Well, they are the rules I mentioned as a first solution and when I tested them, they weren’t working for the Engine problem, which has always been an issue, since I found out about using :style() to create the same cosmetic exceptions #@# does.
I am always finding workarounds to issues, so that’s how I come up with these solutions.

I even checked Devtools and it wasn’t doing what I told it to do, override the display: none !important;) cosmetic filters add to HTML elements.
Now I see it is doing it, don’t know why I am not going to question it, I might test it somewhere else, to see if it is somehow working now.


it was doing crazy stuff, before, but now it is doing the correct thing. Now I am using Latest Nightly with CR119 and the 1.8.2 adblocker though.

Are you using Stable or Nightly?

I mean, when it comes to rules, is no wrong or bad in these as long as they work.

You should have been more clear it was working for you and correct me and say that I should test them again because they were working working, and I would have agreed with you and find it perfect. Since this is a topic I have discussed with devs. I might have to test to see if it happens in other websites.

It is good to have two solutions to a problem, because if people want to learn, they can learn they can use different methods to workaround Brave adblocker limitations, either by unsupported features or meant to be behaviors by Brave devs.

:+1: thanks for informing me so I can go and test further about it.

Yes, testing adding ##body in the Default lists and using block !important;) and it worked. so I guess it works now :+1:

It is good to know there is no need for just ghide, this way it is easier to see which element exactly causes and issue of an antiadblock whatever or something like this where comments don’t show.
But as you can see, there is a difference of ‘engines’, Default can have generic filters, but custom filters/lists/regional lists can’t.
Not hard to modify Default lists, but they get updated so often now (which is good) that it makes it not ideal.

Oh I also noticed that @@||^$generichide was added to Easylist, so There is no need for custom filters anymore.

Funny thing is I noticed this because I saw the ##body not working, since the generichide was in place in the default lists, so I made a search and found it.
Since disqus is an iframe: block !important;) was still needed, making the test interesting and making sure it works for some reason now.

I can confirm that I don’t need custom filters on desktop anymore. iOS still has the issue. I guess we are going to have to wait on @fanboynz to update that.

Seems to be fixed on mobile now too. Don’t know if that was the site changing or brave changing. Thank you all for your help.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.