This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
More complete support of Adblock net filters #231
Description
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).
Activity
gorhill commentedon May 5, 2014
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
domainoption 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.
more work for #231
gorhill commentedon May 12, 2014
Alright, I want to be done with this one before v1.0.
gorhill commentedon May 13, 2014
Currently standing at 97.8% coverage with local changes. Discarding
$popupoption, 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).
gorhill commentedon May 13, 2014
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
$popupthe 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.
re-benchmarked because of changes to ABP filtering engine as per #231
gorhill commentedon May 14, 2014
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.
#231: code review for ABP filtering after spotting anomalies during t…
gorhill commentedon May 16, 2014
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.[-]More complete support of Adblock filters[/-][+]More complete support of Adblock net filters[/+]gorhill commentedon Jun 20, 2014
Supporting left- and right-anchored filters brings coverage to 99.8% (when using EasyList + EasyPrivacy) when not taking into account
$elemhideand$popupoptions.this fixes #302 via #231