Some users have asked for a uBO mode, Brave applies all the same protections as uBO, and can enable them with a single button / toggle.
Right now Brave has all the same capabilities as uBO, with the following excpetions:
Hi, I had a question to your comment as it seemed contracting to the filter compatibility wiki so I tested some of the most important function not mentioned here on Brave Nightly 1.8.11 running on Win10 64 bit.
CSS style injection is not supported, or at least its syntax is different from uBO's one. Not only it is necessary to get scroll functioning after hiding some sort of modal overlay, it can also be used to address some of anti-adblock example.
Obviously not all scriptlets of uBO is supported, or at least don't work in the same way as uBO. For example, nostif doesn't work at all. It's expected as I see no such strings in here or here. Moreover, even supposedly-supported aopr doesn't work e.g. gigaho.com##+js(aopr, onload) doesn't work on the site.
It seems $inline-script modifier doesn't work. No wonder given $csp is not supported according to the wiki, but not mentioned in the wiki.
As stated in the wiki, $ping is not supported.
As stated in the wiki, $popup is not supported.
As stated in the wiki, $generichide is not supported. I think this should be prioritized as well as the above scriptlets issue because the introduction of cosmetic filtering, even only for third-party, without support of those will cause a jump of rates that users come across anti-adblock messages.
It's not meant to be an exhaustive list, but there seems to be really many things to be done.
Finding: nice to see regex filter is now supported, please update the wiki.
It's personal opinion, but I think what should be done ASAP over all the above is to allow user to freely choose subscription filter from anywhere - uBO has been doing this from the beginning.
@Yuki2718 thank you for the comments and findings. We also want to get all these things done, but it's a matter of competing priorities. Some of these things are useful, but (in my best guess) just less useful than the other privacy-preserving things we're working on.
That being said, again, thank you for this. I'm going to share it internally and see where things stand.
One note, as @ryanbr reminded me, the $ping attribute isn't supported because Brave doesn't include ping-functionality (https://github.com/brave/brave-browser/issues/7640)
@pes10k Thank you for clarification and positive answer, I understand you have a priority for various features. My comment was meant to be potential FYI.
@Yuki2718 Style injection should already be supported in exactly the same capacity as uBlock Origin.

Did you find a particular example of a rule whose syntax isn't supported?
Did you find a particular example of a rule whose syntax isn't supported?
Applying
google.*##.mn-dwn-arw:style(top: 27px !important;)
to Google search results in move of arrow icons as

on uBO - for this screenshot I disabled uBO's other filters but keeping them enabled didn't change the results, only changed other appearance such that URL was shown in grey the same as the last screenshot below.
But the same rule on Brave Nightly 1.8.22

didn't

and changing the wildcard to "com" google.com##.mn-dwn-arw:style(top: 27px !important;) didn't make a difference.
This is when uBO's other filters are enabled:

@antonok-edm is this because custom rules are still going through the 1p vs 3p distinction (which i think is good for now)? That might explain what you're seeing @Yuki2718 (see https://brave.com/whats-brave-done-for-my-privacy-lately-episode2/ for more details)
Supporting $generichide would be helpful (used by uBo and EL)
Is it possible to implement something like this in the future?
@pes10k
Like an "This is for advanced users" more granule blocking
Hi @RobertH1999, we're interested in adding more debugging information like this, but I dont think we'll be able to get to it soon so I'll close this (this issue is more for matching uBO capabilities than debugging information / UI). I'm going to close this issue now, but I've added a separate issue to track here: https://github.com/brave/brave-browser/issues/11426
(marking this as duplicate since there is just one related open issue, already being tracked in https://github.com/brave/brave-browser/issues/8559)