Opened 5 years ago

Closed 5 years ago

#2174 closed defect (incomplete)

non typical CSS freezes chrome and firefox

Reported by: mapx Assignee:
Priority: Unknown Milestone:
Module: Core Keywords:
Cc: sebastian, trev, Arthur Blocked By:
Blocking: Platform: Unknown
Ready: no Confidential: no
Tester: Verified working:
Review URL(s):

Description (last modified by 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

Change History (15)

comment:1 Changed 5 years ago by mapx

  • Description modified (diff)

comment:2 Changed 5 years ago by mapx

  • Description modified (diff)

comment:3 Changed 5 years ago by 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);

comment:4 Changed 5 years ago by sebastian

  • Cc Arthur added

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.

comment:5 Changed 5 years ago by 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

Last edited 5 years ago by mapx (previous) (diff)

comment:6 follow-up: Changed 5 years ago by mapx

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

comment:7 in reply to: ↑ 6 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.

Last edited 5 years ago by sebastian (previous) (diff)

comment:9 follow-up: Changed 5 years ago by 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

Last edited 5 years ago by mapx (previous) (diff)

comment:10 in reply to: ↑ 9 Changed 5 years ago by 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.

comment:11 follow-up: Changed 5 years ago by fanboy

comment:12 in reply to: ↑ 11 Changed 5 years ago by 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)

comment:13 Changed 5 years ago by 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?

comment:14 Changed 5 years ago by mapx

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

comment:15 Changed 5 years ago by sebastian

  • Resolution set to incomplete
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.