-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Comments
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). |
Also, the filter blocking |
Here are custom filters to make the site work again:
You may want to include these as suggested filters when you report to EasyPrivacy maintainers. |
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. |
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.
Completely false. Adblock Plus and AdBlock cause the exact same problem when they are used with EasyPrivacy. Care to explain such false statement? |
Sorry, I apologize. I just noticed that the browser slows down in this particular case. Really didn't want to make any false statement. |
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. |
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
The text was updated successfully, but these errors were encountered: