Issue 5015 - Better handle broken element hide filters

Issue 5015 - Better handle broken element hide filters

Based upon the ESLint changes in https://codereview.adblockplus.org/29374674/

[kzar, 2017-03-23 06:31:21]

Patch Set 1

To my surprise this didn't seem to have much, if any, effect on performance. I
tested before and after this change, both with and without the broken filter
list that Mapx created http://axistrivia.altervista.org/list/easylist2.txt .

My test was to open a tab, browse to https://adblockplus.org/, start profiling,
refresh the page 5x and then stop profiling. Results varied but were always
around 150ms for me.

Note I don't worry about the tracing code for our devtools pane, so that fails.
But that's actually quite good, an exception is thrown which specifies which
selector is broken and element hiding still works.

[Sebastian Noack, 2017-03-23 07:11:43]

As I mentioned in the issue, there isn't much of a point anymore to inject the
selectors in batches. In fact, Microsoft even asked us a while ago to inject all
selectors at once (for performance reasons), which however we couldn't do back
then because of Safari, but we probably should do now.

But then, if a filter is invalid, and we fall back to insert each out of ~20k
(instead of just 200) filters individually, this will quite impact the page load
and memory usage of every website (the invalid filter is active on, which likely
is every website). So if we'd do something like that I think we should rather
start injecting all selectors at once, and then bisect if it fails.

However, as I also pointed out in the issue, when (hopefully soon)
chrome.tabs.insertCSS starts using user stylesheets, and we move to that API, we
won't get any error in case there is an invalid filter anymore. Hence this
appears to be only a temporary solution anyway.