Opened 2 years ago

Closed 7 months ago

#6100 closed defect (rejected)

Procedural hiding filter triggers unresponsive page

Reported by: mapx Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords: circumvention, closed-in-favor-of-gitlab
Cc: kzar, mjethani, hfiguiere, sebastian, Lain_13 Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):



windows 7
chrome 63

How to reproduce

  • disable all the lists in ABP
  • add these filters: > iframe

  • go to

Observed behaviour

  • page becomes unresponsive, high CPU


these filters: > iframe

or: > iframe

don't trigger the same behaviour but in the ABP panel (devtools) I can see only the first filter:

The site is using the tricks reported here: #5302
( stuff)

so, could be even fixing #242 it's not enough to fight against similar crap.
(sure, implementing $CSP and managing inline scripts is the right approach..)

Change History (13)

comment:1 Changed 2 years ago by kzar

  • Component changed from Unknown to Platform

comment:2 Changed 2 years ago by Lain_13

There is a good chance that site attached a MutationObserver to that IFRAME object and restores STYLE property which ABP changes. In the result they are going into a fight since ABP also attaches an observer.

comment:3 Changed 2 years ago by mapx

  • Cc Lain_13 added

comment:4 Changed 2 years ago by Lain_13

Just checked and it looks like that's exactly what happens. The simplest way to fix this would be to move code which changes attribute into async function with setTimeout. Otherwise two observers will never return control to the browser and trigger each other forever. With setTimeout browser will postpone change until it have time to execute it. Usually such undercover fight have relatively low footprint (when console is closed) and usually browser defaults to display none. At least it was like that in my experiments about a year ago.

Another way to solve this is to override some API to prevent site from detecting this change at all and/or prevent their code to change style through setAttribute and modify Once I wrote similar code to hide ads on

In RU AdList JS Fixes I have special workaround for this particular ad network which overrides XMLHTTPRequest.prototype.send and ignores calls when it goes to their domain. So, their ads code never runs (except for that "/api" request - it must work).

Last edited 2 years ago by Lain_13 (previous) (diff)

comment:5 Changed 2 years ago by kzar

Hubert please could you look into this one as well?

comment:6 Changed 2 years ago by kzar

  • Platform changed from Chrome to Unknown / Cross platform
  • Summary changed from procedural hiding filter triggers unresponsive page in chrome to Procedural hiding filter triggers unresponsive page

comment:7 Changed 2 years ago by mjethani

I looked into this a little bit. It seems like the page detects Adblock Plus and tries to unhide the iframe, which then causes Adblock Plus to hide it again, and this becomes a never-ending loop in which both the page and Adblock Plus try to apply their own styles to the element. It looks like this is by design on Adblock Plus's part.

comment:8 Changed 2 years ago by kzar

So in the issue description it mentions that implementing $csp would be a suitable approach, we've been working on that in #5241.

Otherwise if the webpage keeps showing the iframe and Adblock Plus keeps hiding it like Manish mentions... I'm not sure what we can do to help which isn't also open to abuse for circumvention. Any suggestions, or shall I close this until we have $csp?

Last edited 2 years ago by mapx (previous) (diff)

comment:9 Changed 2 years ago by Lain_13

At least try to make call to setAttribute async, this should allow page to display and significantly reduce CPU load. And may keep IFRAME hidden since in my experiments browser defaults to display:none while observers are fighting each other. Anything is better than hung up page with high CPU load.

Last edited 2 years ago by Lain_13 (previous) (diff)

comment:10 Changed 2 years ago by hfiguiere

  • Keywords circumvention added

comment:11 Changed 2 years ago by mjethani

This should no longer be an issue on Firefox since we switched to user style sheets, and it will stop being an issue on a future version of Chrome (probably 68).

It should still be addressed for current versions of Chrome though.

Last edited 2 years ago by mjethani (previous) (diff)

comment:12 Changed 22 months ago by mjethani

Update: We are still waiting on Chromium to implement tabs.removeCSS.

I don't think it's worth trying to address this without user style sheets.

comment:13 Changed 7 months ago by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Note: See TracTickets for help on using tickets.