Skip to content

Loading…

Massive blocked iframe on some facebook sites #36

Closed
semenko opened this Issue · 8 comments

2 participants

@semenko

Perhaps this is what's meant by the disclaimer for the anti-facebook list, but a number of sites that use to embed facebook content end up with huge blocked icons (the iframe height &amp; width are 1000px ea):</p> <p>e.g. <a href="http://www.monoprice.com/Product?c_id=104&amp;cp_id=10401&amp;cs_id=1040115&amp;p_id=9436&amp;seq=1&amp;format=2">http://www.monoprice.com/Product?c_id=104&amp;cp_id=10401&amp;cs_id=1040115&amp;p_id=9436&amp;seq=1&amp;format=2</a></p> <p>I figured &quot;Hide placeholders of blocked elements&quot; would hide that enormous iframe, but it doesn&#39;t.</p> <p><img src="https://cloud.githubusercontent.com/assets/167135/3448367/36d13c5e-0158-11e4-898f-72f12b7c1e9f.png" alt="blocked"></p>

@gorhill

To me it looks like Fanboy is missing a filter to go with the other Facebook filters. Can you try: ||connect.facebook.net/*/all.js^$third-party?

Looks like I will need a project list to fix Fanboy's annoyance and Fanboy Anti-Facebook until (and if) they add the missing filter.

Other way to address this would be to also listen to attribute changes in the mutation observer, but this is something I am trying to avoid (overhead etc.) So I see the above filter as logically missing in the relevant filter list.

Edit: updated to use a * in lieu of en_US.

@semenko

Ah nice, that does the trick.

@gorhill

Just for the record, I don't think ABP would have suffered the same problem, because it listens to all load events, while uBlock listens only to the ones from elements which have not have their src property set (that could be a problem in certain cases, but I want to try the lower overhead angle first). Either ways, using above filter is the right thing to do, as otherwise users are still hitting 3rd-party Facebook server.

@gorhill

Submitted suggested fix to Fanboy's forum.

@semenko

Awesome -- thanks again.

I love the focus on keeping uBlock's overhead incredibly low. I get the sense a lot of people avoid ABP & similar extensions due to CPU overhead on thin-ish clients like Chromeboxes (It's an ongoing problem we face with HTTPS Everywhere).

@gorhill

Answer from fanboy:

Would break facebook comments; add the Anti-Facebook sub from https://www.fanboy.co.nz if you don't mind blocking facebook comments.

Enabling Fanboy Anti-Facebook didn't work. Yet I see this filter in the list: ||connect.facebook.net^$third-party,domain=~facebook.com, which means it should be blocked. Investigating.

@gorhill

Interesting, this issue allowed to uncover a nasty bug which affected filters using the ~example.com filter option. Once this bug is fixed, the suggestion from Fanboy will work, or else the other workaround of using the custom filter ||connect.facebook.net/*/all.js^$third-party. I will open issue for the uncovered filter bug though, it deserves its own issue.

@gorhill gorhill added a commit that referenced this issue
@gorhill gorhill this is for #84, #70, #53, #36 b82742d
@gorhill

Fixed in 0.2.3.2.

@gorhill gorhill closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.