Procedural hiding filter triggers unresponsive page

[mapx]

Environment

windows 7
chrome 63
ABP 3.0.1.1939

How to reproduce

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

postimg.org##.td-ad
postimg.org#?##td-image > iframe

• go to https://postimg.org/image/443rhpfcaj/

Observed behaviour

• page becomes unresponsive, high CPU

Notes

these filters:
postimg.org#?#.td-ad
postimg.org#?##td-image > iframe

or:
postimg.org#?#.td-ad
postimg.org###td-image > iframe

don't trigger the same behaviour but in the ABP panel (devtools) I can see only the first filter:
postimg.org#?#.td-ad

The site is using the tricks reported here: #5302
(piguiqproxy.com/api 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..)

[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.

[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 node.style.display. Once I wrote similar code to hide ads on 4pda.ru.

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).

[kzar]

Hubert please could you look into this one as well?

[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.

[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?

[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.

[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.

[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.

[sebastian]

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