Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hang up loading page, generating thousands of request blocks #759

Closed
fabrica64 opened this issue Sep 28, 2015 · 7 comments
Closed

Hang up loading page, generating thousands of request blocks #759

fabrica64 opened this issue Sep 28, 2015 · 7 comments

Comments

@fabrica64
Copy link

Acessing page:

http://www.lastampa.it/2015/09/27/sport/motomondiale/ad-aragona-vince-lorenzo-rossi-terzo-dopo-una-battaglia-con-pedrosa-GG0RYbJ1302QQNIuUEDGpJ/pagina.html

uBlock Origin (1.1.1) begins generating hundreds of block requests per seconds, hanging up page load:

09:56:39 /quantcast/* -- script http://www.eplayerhtml5.performgroup.com/js/tsEplayerHtml5/js/Eplayer/js/quantcast/quant.js?version=2015.09.23-10:00

Chrome Version 45.0.2454.101 m on Windows 7

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2015

It's just a badly coded web page, which causes the page to crap itself if something "unexpected" happens, like a network request failing: not a uBlock issue. Contact the web master of the page, this is their issue. Blocking 3rd-party frames solves the issue (blocking 3rd-party frames is a recommended good habit btw if one can handle the occasional web site breakage which can occur as a result).

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2015

Also, the filter blocking http://www.eplayerhtml5.performgroup.com/js/tsEplayerHtml5/js/Eplayer/js/quantcast/quant.js?... is /quantcast/* in EasyPrivacy, you should report the issue to EasyPrivacy maintainers: https://forums.lanik.us/viewforum.php?f=64.

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2015

Here are custom filters to make the site work again:

! 28/09/2015, 09:37:00 lastampa.it
@@||eplayerhtml5.performgroup.com/js/tsEplayerHtml5/js/Eplayer/js/quantcast/quant.js$script,domain=eplayerhtml5.performgroup.com
@@||eplayerhtml5.performgroup.com/js/tsEplayerHtml5/js/Eplayer/js/quantcast/vquant.js$script,domain=eplayerhtml5.performgroup.com

You may want to include these as suggested filters when you report to EasyPrivacy maintainers.

@fabrica64
Copy link
Author

Yes, the filter is in easyprivacy list. The problem here is that uBlock Origin enters a loop. It's certainly a badly coded page but the loop is annoying as it slows down the browser operations. AdBlock and AdBlock Plus with the same list don't loop, just block the script.

@gorhill
Copy link
Owner

gorhill commented Sep 28, 2015

uBlock Origin enters a loop

Incorrect.

uBlock does not enter a loop, a javascript loaded by the web page enters a loop whereas it keeps firing up network requests, it's not uBlock firing these network requests, uBlock merely blocks them because these network requests match a filter in EasyPrivacy.

AdBlock and AdBlock Plus with the same list don't loop, just block the script

Completely false.

Adblock Plus and AdBlock cause the exact same problem when they are used with EasyPrivacy.

Care to explain such false statement?

@fabrica64
Copy link
Author

Sorry, I apologize. I just noticed that the browser slows down in this particular case. Really didn't want to make any false statement.

@gorhill
Copy link
Owner

gorhill commented Sep 29, 2015

I just noticed that the browser slows down in this particular case.

Using Task Manager, I see that the web page CPU usage is ~80%, while uBlock itself is 95%. With Adblock Plus, I get 40% and 110% respectively. So this means with uBlock, for this specific problematic scenario, the web page will use more CPU cycle -- and hence may be less responsive as a result.

I think the most likely explanation I can think of is that uBlock Origin is faster at filtering network requests. This will cause the javascript of the web page to have to deal with more blocked network requests per second, meaning it will have to execute its (buggy) network request-firing code probably more than twice than it would with Adblock Plus.

This matches pretty well the CPU benchmarks I have run for uBlock/ABP regarding how fast they deal with network filtering (last benchmark was averaging roughly 160us vs. 360us per network request for uBlock and ABP respectively).

In plain words, this means the web page has to wait less before receiving an answer about the result of its request for resources with uBlock than it does with ABP. With the current buggy scenario, this means it will do more work per unit of time. Under normal circumstance however, having a web page wait less on an extension is the desired behavior.

Sorry for the harsh words, there are just too many myths out there regarding uBlock and I wouldn't want another one popping up. I am fine with someone pointing out whatever uBlock shortcoming there might be, so long as this is technically accurate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants