Counter increases without stopping

[SMed79]

Environment

Linux & Win
Firefox 48 / Adblock Plus 2.7.3
Chromium 51 / Adblock Plus 1.12.1

How to reproduce

1. Add the filter ||mon-compte.org/img/probleme-compte.png
2. Go to » http://mon-compte.org/skype/

Observed behaviour

The hits counter of blocked elements increments into infinity.

Expected behaviour

The hits counter of blocked elements should stop counting.

What to change

• When the blocked count reaches 500 set the icon badge text and the respective text in the icon popup to ∞.
• Don't update the page-specific blocked count or the icon badge text anymore after that to avoid unnecessary CPU usage.
• Keep incrementing the total blocked count.

See also ​ui#222.

[mapx]

Probably would be useful a more general approach: stop such blocking after "n" occurrences for any blocked element (excepting multi frames pages as youtube, facebook ..)

[mapx]

however in this case enough using this hiding filter

mon-compte.org##IMG[src="http://mon-compte.org/img/probleme-compte.png"]

[sebastian]

It seems that if that image fails loading, a script on that page keeps reloading it forever. I suppose the ad counter going up in that case would be the expected behavior, as Adblock Plus is effectively blocking that image again every time the page re-tries loading it.

Not blocking repeated requests, as mapx suggests, is probably a very bad idea, as websites would be able to easily circumvent us then by simply re-sending requests.

[greiner]

Expected behaviour
The hits counter of blocked elements should stop counting.

Why is that the expected behavior? If the site is requesting some resource infinitely many times then the counter should reflect that. That way you can at least see that there's an issue with the site when, for instance, your CPU usage increases all of a sudden. Therefore I'd consider this to be a feature, not a bug.

The real issue I see is that it currently looks like a problem with Adblock Plus, not a problem with the website. There should be some way to improve the user experience for this case so I added Aaron to CC.

[trev]

I think the request isn't really about stopping to block things, rather about not counting the same resource multiple times. Regardless of whether this is a good idea in the first place, it won't work under all circumstances either - e.g. requests made by jQuery always have a unique URL even when requesting the same resource.

In this particular case there is clearly an issue with this webpage - it keeps requesting the same images each second, regardless of whether these are blocked (visible in Diagnostics on Firefox as well). While I couldn't find the problematic code immediately, I guess that there is some innerHTML manipulation going on there.

Either way, the only meaningful solution that I can see is restricting this counter - e.g. displaying "99+" if it runs too high (we can still show the exact number in the bubble). This should also limit the annoyance factor here.

[mapx]

perhaps in this case it is not a real CPU high-usage problem but in many other cases (especially in chrome) it is. It's the reason of my suggestion (eventually attaching a counter on filter and not on request).
Alternatively establishing a general limit number of blocking events on page (available eventually as an option parameter to be modified by the advanced users).

[trev]

Feel free to provide examples of "many other cases" (as a separate issue, not related to the one here) - I am only aware of one such case where blocking a tracking request made the script go into an endless loop. Generally, not blocking isn't a good solution.

[mapx]

examples (including browser crashing, high cpu)
only few:
​https://adblockplus.org/forum/viewtopic.php?f=2&t=25056&p=106806&hilit=infinite#p106806
​https://adblockplus.org/forum/viewtopic.php?f=18&t=47301&p=156438&hilit=counter#p156438
​https://adblockplus.org/forum/viewtopic.php?f=10&t=45698&p=152942&hilit=counter#p152942
​https://adblockplus.org/forum/viewtopic.php?f=2&t=25056&p=106762&hilit=counter#p106762
​https://adblockplus.org/forum/viewtopic.php?f=10&t=24670&p=106743&hilit=counter#p106743
​https://forums.lanik.us/viewtopic.php?f=64&t=20950&p=66785&hilit=loop#p66785
​https://forums.lanik.us/viewtopic.php?f=64&t=28915&p=76725&hilit=loop#p76725
​https://forums.lanik.us/viewtopic.php?f=64&t=22507&p=69819&hilit=loop#p69819

[greiner]

Either way, the only meaningful solution that I can see is restricting this counter - e.g. displaying "99+" if it runs too high (we can still show the exact number in the bubble). This should also limit the annoyance factor here.

I disagree since the issue is not that the counter grows to large but that the website doesn't follow best practices. Anyway, I'd rather leave this to our user experience designers.

[jeen]

Hi all, I agree that the problem isn't the counter, but about making the user aware that there is a problem with something on the web page itself. The notification bubble in this case, should look and behave slightly differently to normal to demonstrate that there is a problem. A counter going up to infinity can alert the user to the problem, but as Greiner pointed out 1) it can look like there is a problem with the extension 2) it doesn't explain the problem to the user , and 3) is also distracting.

I imagine having either a static alert after n instances so either it goes to 99+, or shows an infinity symbol - perhaps it glows to draw attention to it? And within the menu, include additional information: a warning message relating to the problem, and provide suggestions on what to do -i.e. restart your browser, close your tab etc.

[mapx]

The real issue is high cpu usage or even browser / system crash. If you visit a page like that and for some reason go away for 10 minutes or more .. or even change the tab, your system/ browser will crash.

For the user this is an extension issue. Even providing an alert message, there are pages where the counter will show thousands blocked elements in 1-2 minutes. This means you can do nothing (memory / CPU usage 100%).

[SMed79]

Replying to mapx:

This means you can do nothing (memory / CPU usage 100%).

The first time i didn't pay attention to the counter until i noticed that my browser / system slow.

[greiner]

Replying to jeen:

I imagine having either a static alert after n instances so either it goes to 99+, or shows an infinity symbol - perhaps it glows to draw attention to it?

Note that there are legitimate scenarios when we block more than 99 requests on a page (e.g. when you browse through YouTube the counter never resets because you never leave the page). Maybe we could determine how fast the counter is changing so that only if a lot of requests were blocked within a short period of time, we'd stop the counter and show the proposed "∞" symbol.

Anyway, I'm open to other suggestions on how to determine when to switch to infinity and I agree that in combination with the info text in the icon menu, this could be a good solution. Hopefully, that way we can educate users how they can deal with the problem without annoying them with our counter.

[jeen]

Replying to greiner:

Note that there are legitimate scenarios when we block more than 99 requests on a page (e.g. when you browse through YouTube the counter never resets because you never leave the page). Maybe we could determine how fast the counter is changing so that only if a lot of requests were blocked within a short period of time, we'd stop the counter and show the proposed "∞" symbol.

Yes showing "∞" based on the speed at which the counter is increasing at is a good solution.

Although if the user has switched to a different tab, this still would not alert the user to the problem. Is there a way we could somehow show in the favicon that there is unusual behaviour on a tab?

[mapx]

another example:
​http://www.natureworldnews.com/

only easylist enabled, main page, keep scrolling the page.

And again, it's not about an aesthetic / cosmetic / notification issue. It's about system resources, high cpu usage, crashes, please don't ignore all these things.

[SMed79]

Something is planned here to improve the user experience?

[greiner]

Thanks for bringing this up again. Looking at it again, I tend to disagree that we should alert the user of a problem because it isn't actually one.

We have yet to figure out when to switch over to infinity though and on that front I'm disagreeing with my own assessment because lots of requests may be blocked in a short time during page load.
Instead, switching the counter over at a certain amount of blocked requests (e.g. 500) seems more intuitive so I've updated the ticket description to outline my proposal.

[greiner]

Added link to GitLab issue.

[SMed79]

At www.dotmsr.com, I am getting a high CPU usage because of the ​~200 hits per second to https://api.ipify.org/?format=json blocked by EasyPrivacy.

[greiner]

I can't reproduce that issue but it sounds like it needs to be fixed in the code which makes those requests because that's not a good way to handle failing requests regardless of what's causing them to fail.

[huonglam]

spam

[sebastian]

For reference, the issue with rapidly increasing filter hits shown in the icon badge causing high CPU load has been mitigated with #7257.

[greiner]

Closing this ticket in favor of ​ui#222.