non typical CSS freezes chrome and firefox

[mapx]

Environment

firefox 37, chrome 42
last ABP for both

How to reproduce

go to
​http://axistrivia.altervista.org/test.html

-high CPU usage (50%), the page in endless loading, freezes
-even closing the page (in chrome) ABP will still remain in high CPU usage
-disable easylist ==> the page is loaded correctly, no freezing

comment from the user who reported the issue:
The problem is the non typical CSS href

in forum
​https://adblockplus.org/forum/viewtopic.php?f=1&t=28886

[sebastian]

I can reproduce it. Following filter match takes forever:

defaultMatcher.matchesAny("http://site.com/skin/m/1426086915/skin/frontend/base/default/css/widgets.css,/skin/frontend/base/default/dededededede/css/checkoutbyamazon.css,/skin/frontend/base/default/deded/allreviews/allreviews.css,/skin/frontend/base/default/css/dededede_searchindex.css,/skin/frontend/base/default/dededededede/css/checkoutbyamazon.css,/skin/frontend/base/default/deded/allreviews/allreviews.css,/skin/frontend/base/default/css/dededede_searchindex.css,/skin/frontend/base/default/dededededede/css/checkoutbyamazon.css,/skin/frontend/base/default/deded/allreviews/allreviews.css,/skin/frontend/base/default/css/dededede_searchindex.css,/skin/frontend/base/default/dededededede/css/checkoutbyamazon.css,/skin/frontend/base/default/deded/allreviews/allreviews.css,/skin/frontend/base/default/css/dededede_searchindex.css,/skin/frontend/base/default/css/deerrrrr/ajaxdsadsadaslogin/ajaxlogin.css", "stylesheet", "axistrivia.altervista.org", true, null);

[sebastian]

This issue effects any URL with a notable amount of alphanumeric sequences separated by special characters (like the /, , and . here). It seems that following filter from EASYList is to blame:

/http://[a-zA-Z0-9]+\.[a-z]+\/.*[a-zA-Z]{2}.*(?:[!"#$%&'()*+,.:;<=>?@/\^_`{|}~-]).*[a-zA-Z]{2}.*(?:[!"#$%&'()*+.,:;<=>?@/\^_`{|}~-]).*[0-9]+/$script,third-party,domain=247wallst.com|activistpost.com|allenbwest.com|americanlivewire.com|askmefast.com|blacklistednews.com|breathecast.com|brosome.com|chacha.com|cheezburger.com|christianpost.com|christiantoday.com|cinemablend.com|classicalite.com|crossmap.com|dailycaller.com|dealbreaker.com|designntrend.com|digitaljournal.com|gamerant.com|hallels.com|hellou.co.uk|hngn.com|infowars.com|investmentwatchblog.com|joblo.com|kdramastars.com|kpopstarz.com|latinpost.com|listverse.com|makeuseof.com|moddb.com|mstarz.com|musictimes.com|naturalnews.com|natureworldnews.com|newser.com|oddee.com|okmagazine.com|opposingviews.com|politicususa.com|radaronline.com|realfarmacy.com|screenrant.com|techtimes.com|theblaze.com|thefreedictionary.com|thegatewaypundit.com|theladbible.com|thelibertarianrepublic.com|townhall.com|unilad.co.uk|uniladmag.com|unitrending.co.uk|valuewalk.com|vcpost.com|viralnova.com|whatculture.com|wimp.com|wwitv.com

Only matching this filter alone against the URL above takes several minutes, which isn't a surprise due to a regular expression with exponential complexity.

[mapx]

why - even closing the page in the case of freezing above - ABP is still "working" ?!
-probably some listener would be necessary (in case of a closed tab) to interrupt the ABP work

[mapx]

-probably the matcher stuff should have some predefined time after that ... continue with the other matchings

[sebastian]

Replying to mapx:

why - even closing the page in the case of freezing above - ABP is still "working" ?!
-probably some listener would be necessary (in case of a closed tab) to interrupt the ABP work

The filter matching happens in the extension's background page, not in the tab's process. And while the background page is busy, new events and requests for the extension have to wait.

Replying to mapx:

-probably the matcher stuff should have some predefined time after that ... continue with the other matchings

This wouldn't work, because it's not the amount of operations involved but one particular atomic operation that takes very long here. That is the call to RegExp.match() with the regular expression and URL above.

[sebastian]

I filed a separate issue (#2177) and already uploaded a patch, to perform the regexp match - as it is the most expensive operation - last, after all the other checks (request type, document domain, etc.). This prevents that regular expression from being matched for this particular request. And should slightly improve the overall performance. But I think the filter responsible here should still be removed or optimized in EasyList, since it will take a while until that improvement lands into the releases. And even then, it might still cause issues under some less likely circumstances.

[mapx]

yep, I see. Can you set a timeout for a function (user function or a builtin function) in JS ?
(like this one: ​https://msdn.microsoft.com/it-it/library/twcw2f1c%28v=vs.110%29.aspx )

anyway 2177 should improve the performance and avoid unnecessary checks I guess

[sebastian]

Replying to mapx:

yep, I see. Can you set a timeout for a function (user function or a builtin function) in JS ?
(like this one: ​https://msdn.microsoft.com/it-it/library/twcw2f1c%28v=vs.110%29.aspx )

I'm not aware of any CPU-bound built-in function that supports a timeout like that one.

Though it's theoretically possible to run JavaScipt code in a background thread using the ​Web Workers API. So you can run code in parallel and/or force it to terminate at any time. However, beside I haven't tried out yet whether extensions can actually use web workers, their API is asynchronous. But we have to respond synchronously when matching requests to potentially block them. So we can't use them here. Not that I think this would be a good idea anyway, since it adds some overhead and quite some complexity.

You could still implement user functions that check how many time has elapsed after each (or every few) operation(s) and return when the timeout has exceeded. But this only works as expected as long as the time spend for the individual operations is predictable and smaller than the timeout. So this won't work here either, and would also add some overhead.

[fanboy]

​https://hg.adblockplus.org/easylist/rev/afe3fb79cc4c

Does this commit help?

[mapx]

Replying to fanboy:

​https://hg.adblockplus.org/easylist/rev/afe3fb79cc4c

Does this commit help?

still freezing in chrome
in firefox is working due to the last build (based on #2177)

[sebastian]

I tested with Chrome 41.0.2272.89 and Adblock Plus 1.8.12 as well as the devbuild (#2177 isn't merged there yet). And after updating EasyList that filter match only takes a couple of millisencods for me. I also tested without filter subscriptions, just comparing the new and old version of that filter and it seems that the change helped a lot.

It might be that you tried to early. It takes some time the filter lists are generated on the server after changes are pushed. Can you manually update EasyList and try again?

[mapx]

right, not freezing at all, probably I tested too early

[sebastian]

Ok, closing as incomplete now, since it was mainly a filter list issue which has been resolved.