Twitter sidebarColumn blocking stopped working

Browser Support Desktop Support
#1

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’:

twitter.com##div[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?

#2

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

#3

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.

#4

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.

#5
  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).
#6

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.

#7

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.

#8

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

#9

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?

#10

I have no answer here, it works for me.

twitter-rightside

#11

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.

#12

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

#13

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