Opened 14 months ago

Last modified 14 months ago

#6598 new defect

Element hiding filters covering iframes with display: block !important style hide too much

Reported by: arthur Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords:
Cc: amrmak, mjethani, sebastian, kzar, mapx Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by mjethani)

Environment

Chrome 66.0.3359.117 (Official Build) (64-bit)
ABP 3.0.3.2011
EasyList enabled

How to reproduce

  1. Add these two custom filters to ABP

coed.com##iframe[style="display: block !important; height: 310px !important; width: 100% !important; visibility: visible !important; border: 0px !important;"]
pocketnow.com##iframe[style="display: block !important; height: 600px !important; width: 100% !important; visibility: visible !important; border: 0px !important;"]

  1. Go to this page and this page.

Observed behaviour

Sometimes the page looks very broken or completely blank.

Expected behaviour

The pages should show properly, the top ad on coed.com should be hidden, the ad at the bottom on pocketnow.com should be hidden.

Notes

This doesn't seem to happen in every case where these circiumvention ads (Uponit) are used. It works fine on phonesreview.co.uk removed by phonesreview.co.uk##iframe[style*="display: block !important;"] in EasyList.

The issue looks very similar to #6298, though reducing the selector group size to 256 or even 16 in lib/cssInjection.js doesn't seem to improve the situation.

Change History (15)

comment:1 Changed 14 months ago by amrmak

  • Cc amrmak added

comment:2 Changed 14 months ago by mjethani

  • Cc mjethani sebastian kzar added

comment:3 Changed 14 months ago by mjethani

  • Description modified (diff)

comment:4 Changed 14 months ago by mapx

  • Cc mapx added

comment:5 Changed 14 months ago by mapx

In uBo the page is broken too. Could be intentional ?!

However, in uBo it's the alternative (injecting filters)
https://github.com/uBlockOrigin/uAssets/commit/e1471849ac43181b4aa1328a79a8904b40303ba6

comment:6 Changed 14 months ago by mjethani

@mapx do you mean that adding this script:inject filter fixes the issue on uBO?

comment:7 Changed 14 months ago by mapx

Sure.

comment:8 Changed 14 months ago by mapx

Well, I mean add that inject filter but without the hiding filter above.

comment:9 Changed 14 months ago by mapx

However, you can even add the hiding filter, no effect anymore (probably because the trick is wiped out by the injecting filter)

comment:10 Changed 14 months ago by mjethani

@mapx thanks, that really helps.

comment:11 Changed 14 months ago by mapx

Other observation:

in uBo is working as well (I mean stopping the ads):
coed.com##script:inject(nowebrtc.js)

but in ABP $webrtc does not work: ||coed.com^$webrtc

chrome://webrtc-internals/ => still showing all the opened webrtc channels

Last edited 14 months ago by mapx (previous) (diff)

comment:12 Changed 14 months ago by mapx

working filter (courtesy of gorhill)

coed.com#?#div[id]:-abp-has(> iframe[id]:not([src]))

comment:13 Changed 14 months ago by mapx

Using Arthur's filter above and adding minimum width, height (via :style in uBo which can add / modify styles) is working fine in uBo (so probably - as gorhill is supposing - the scripting code downloaded via webrtc is testing if the iframe used for ads has a width or height of 0)

coed.com##iframe[style="display: block !important; height: 310px !important; width: 100% !important; visibility: visible !important; border: 0px !important;"]:style(width: 1px !important; height: 1px !important;)

However this does not explain why this 1 is working:
coed.com#?#div[id]:-abp-has(> iframe[id]:not([src]))

Last edited 14 months ago by mapx (previous) (diff)

comment:14 follow-up: Changed 14 months ago by mjethani

It seems it has nothing to do with the filters in question. I'm not fully sure about this, but it seems that once the page finds out that some ads are blocked it tries to rewrite the content, but because some of the scripts are blocked too it doesn't succeed in rewriting new content. The final HTML contains no content, only a (empty) header and a (empty) footer.

I have seen this behavior even when these filters don't match but some old (generic?) filters in EasyList match.

comment:15 in reply to: ↑ 14 Changed 14 months ago by mjethani

Replying to mjethani:

I'm not fully sure about this, but it seems that once the page finds out that some ads are blocked it tries to rewrite the content, but because some of the scripts are blocked too [emphasis added] it doesn't succeed in rewriting new content.

So this problem should not occur if EasyList is not enabled and these are the only filters, it would be nice if someone could confirm.

Note: See TracTickets for help on using tickets.