Opened 21 months ago

Last modified 15 months ago

#6100 new defect

Procedural hiding filter triggers unresponsive page

Reported by: mapx Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords: circumvention
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):

Description

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

Change History (12)

comment:1 Changed 21 months ago by kzar

  • Component changed from Unknown to Platform

comment:2 Changed 21 months 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 21 months ago by mapx

  • Cc Lain_13 added

comment:4 Changed 21 months 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 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).

Last edited 21 months ago by Lain_13 (previous) (diff)

comment:5 Changed 21 months ago by kzar

Hubert please could you look into this one as well?

comment:6 Changed 21 months 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 20 months 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 19 months 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 19 months ago by mapx (previous) (diff)

comment:9 Changed 19 months 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 19 months ago by Lain_13 (previous) (diff)

comment:10 Changed 17 months ago by hfiguiere

  • Keywords circumvention added

comment:11 Changed 16 months 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 16 months ago by mjethani (previous) (diff)

comment:12 Changed 15 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.

Note: See TracTickets for help on using tickets.