More complete support of Adblock net filters

[gorhill]

As of today, HTTPSB parses and enforces over 75% of ABP's request-blocking filters, or nearly 90% if not counting whitelist filters. Do whatever can be done to improve ABP-filters coverage.

Also, I cleared my misunderstanding of ABP's whitelist filters: I had assumed these were strictly for so-called "acceptable ads", while their only purpose [in EasyList, EasyPrivacy, etc.] is to un-break specific pages which are broken by ABP-blocking filters (The "acceptable ads" filters are in another standalone list, which is not and will never be supported by HTTPSB - because I believe the only acceptable ads are one the ones the user himself/herself decides to allow, not what a 3rd-party decides based on that 3rd-party's own definition).

[gorhill]

With EasyList + EasyPrivacy, the filter support coverage as of writing is 84.5%, and with support of whitelist filters, it would be 87.9%.

The domain option appears to be the currently unsupported one which is most used (third-party, now supported, was the most used).

I think v1.0 should support whitelist filters (which purpose is to unbreak web sites), but for now I don't see it as an emergency to further extend coverage.

I want the ABP filtering engine to grow sanely (i.e. priority is CPU and memory efficiency), so I rather take my time for support of the statistically less common filtering cases.

[gorhill]

Alright, I want to be done with this one before v1.0.

[gorhill]

Currently standing at 97.8% coverage with local changes. Discarding $popup option, I don't see it documented there. The site reported in #262 works properly now with the extended coverage.

Now analyzing impact on performance. Appears that the number of visited filters per URL is still low on average (~8).

[ghost]

Regarding the $popup option, this is what I've found:

https://adblockplus.org/development-builds/experimental-pop-up-blocking-support

[gorhill]

Thanks for the link.

So I understand that filters with this option are on the same level as element hiding filters, it's just that they apply to popup windows (chromium has a built-in popup blocker) rather than DOM elements, i.e. they are not to be used to block net requests, which is the primary purpose of HTTPSB.

So if I discard $popup the same way I discard element hiding, that should give HTTPSB a coverage of net request-based ABP filters quite close to 100%. I will measure and write down the result here later.

Edit: 99.7%. Good enough for v 1.0.

[gorhill]

Because of this https://blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-on-firefoxs-memory-usage/comment-page-1/#comment-11173, I think a companion extension to handle strictly element hiding filters is more and more tempting, given how ABP is unoptimized with its handling of element hiding filters -- though I would have to check that the statement also applies to ABP on Chromium.

[ghost]

... or to Adblock (without Plus) which might handle it in a different way.

I understand your stance to create a companion extension which handles element hiding. On the other hand, I still think - if you find a lean and better way how to do it compared to ABP - that most HTTPSB users would prefer to have it in one place rather than installing an additional extension.

[gorhill]

Actually, looking at what is rejected by the engine, I see filters in the form |http..., meaning filters which are anchored to the start of a URL. These are easy to support with no consequence whatsoever on performance etc., so I will go ahead and put in code for these when I feel doing so. There are not many of these rejected filters, but I see it more useful for people who wants to add their own filters, they would end up wondering why it's not working despite following the filter syntax as per ABP doc.

[gorhill]

Supporting left- and right-anchored filters brings coverage to 99.8% (when using EasyList + EasyPrivacy) when not taking into account $elemhide and $popup options.