Changes between Version 8 and Version 17 of Ticket #5464


Ignore:
Timestamp:
08/24/2017 11:15:37 AM (2 years ago)
Author:
mjethani
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5464

    • Property Status changed from new to closed
    • Property Resolution changed from to fixed
    • Property Priority changed from Unknown to P4
    • Property Milestone changed from to Adblock-Plus-for-Safari-next
  • Ticket #5464 – Description

    v8 v17  
    55Update the `dependencies` file to point to the latest version of `abp2blocklist`. 
    66 
    7 Since the safari version of `adblockpluschrome`'s `adblockpluscore` dependency does not support WebRTC yet, either update that dependency, or somehow hack around it in `abp2blocklist` by patching `RegExpFilter.typeMap` within `lib/abp2blocklist.js` itself. 
     7Since the safari version of `adblockpluschrome`'s `adblockpluscore` dependency does not support WebRTC yet, patch `RegExpFilter.typeMap` in `lib/requestBlocker.js` by adding a new property called `WEBRTC` with a value of `256`. 
    88 
    99Make appropriate changes to `safari/contentBlocking.js` to use the new asynchronous version of the `generateRules` function. 
     10 
     11=== Hints for testers === 
     12 
     13This update should affect the behavior of the extension only when Safari's native content blocking is enabled. 
     14 
     15Please see the issues #5248, #4329, #4327, #5332, #5345, #5325, #5283, and #3673 for details on all the changes that have gone into this update. Ad blocking as well as whitelisting should be a lot more accurate now. 
     16 
     17In some cases it is not possible to translate an EasyList filter exactly into a native content blocking rule. In such cases, we err on the side of ''not'' blocking rather than blocking. There will still be some false negatives (ads not being blocked), but there should be few or no false positives. Any false positive, especially where the content has been ''explicitly'' whitelisted but is ''still'' being blocked, should be considered a bug. 
     18 
     19After a new filter subscription is added, it can take up to 30 seconds for it to take effect, and this delay is expected where the filter list is too large (e.g. currently EasyList+EasyList Germany+AA). During this delay the browser may slow down as the extension compiles the rule set in the background, but it should not freeze completely. 
     20 
     21In some cases the generated rule set may be too large despite #3673 and the extension will throw an error as it did before this update.