Twitter sidebarColumn blocking stopped working

After a recent restart, a Twitter element I had previously successfully blocked via Block Element has started reappearing. I’m unsure if a Twitter change, a Brave regression, or some combo is to blame.

Using the [right-click]->Brave->‘Manage custom filters’ option – which I don’t recall existing a while ago? – I can see the relevant rule at brave://adblock/ under ‘Custom Filters’:[data-testid="sidebarColumn"]

And, if I inspect the page, the element is still uniquely identified via a data-testid="sidebarColumn" DIV attribute.

Anything that could have broken CSS-rule blockers recently?

The area where the rule is viewable includes a comment, “! Filters migrated from ‘Right click > Brave > Block element via selector’”, & I can’t remember being able to review items that had been blocked via that menu before. But I also remember such rules working!

Any ideas to restore the broken functionality?

I just tested the rule in Release, Beta, and Nightly. works in all 3 here @gojomo Does Aggressive mode help?

I’m in Version 1.26.77 Chromium: 91.0.4472.164 (Official Build) (x86_64) on MacOS

What’s ‘aggressive mode’?

Today in repeated probes, I’m noticing it sometimes working, and sometimes not - almost as if some thread devoted to this task is sometimes dead, but occasionally restarted & working for a while.

Given a similar report last year that was fixed by a re-install – Block element via selector has stopped working – I may try that, but unsure if that’ll lose my open window/tab state.

  1. Click on the Brave Shields icon in the address bar.
  2. If you’re using the default Brave Shields settings, the first option should be Trackers & ads blocked (standard).
  3. Change the option to Trackers & ads blocked (aggressive).

Thanks! Alas, toggling ‘aggressive’ on hasn’t reliably restored the prior functionality.

Oddly, I’m not seeing the data-testid="sidebarColumn" element on all Twitter pages - almost as if some element-removal process is sometimes working, and sometimes erroring before success.

Still hoping for ideas on how to debug this, as a the Brave function that used to be reliable is now broken.

One added wrinkle: sometimes the column is empty, & I don’t think it’s Twitter turning it off. It’s almost as if the Brave element is sometimes working, but other times not - even within the same browser launch.

Still works for me. An alterative filter would be[class^="css-1dbjc4n r-aqfbo4 r-zso239 r-1hycxz"]

Still broken for me, & still also (even without a browser relaunch) sometimes seeming to work on page reloads for a range of time, and then for another range not. Almost like some separate stripping thread is sometimes crashed, sometimes running!

Does that pattern suggest any particular debugging approaches?

I have no answer here, it works for me.


Good to know. But, I’m still seeing it work intermittently, with no clear correlation to what I’m doing, across multiple Brave updates.

Does anyone with knowledge of Brave & ad-blocker internals have a theory that could explain:

  • why it’d be broken for some but not others?
  • why it might spontaneously work for a while, then not, then work again?

That pattern suggests to me some sort of helper process, which is sometimes hitting crash-input – perhaps a site I’m visiting or have open in some tab that you’re not – that temporariliy disables it, but also sometimes restarting after a normal interval/action.

Curious, does it work for you if using the alternative data-testid="sidebarColumn" specification? (Which, AFAICT, both should work & used-to-work.)

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