Adguard preprocessor directive to load sublist only when using Adguard iOS App [2020-09-08: Adguard Android App Exclusion List Added]

[yourduskquibbles]

Describe the issue

I would like to use exclusion filters in a sublist that will only get loaded when the client is detected to be adguard on iOS to workaround cosmetic display issues caused by CSS style modification "companion" filters that end up incorrectly removing extra spacing/content that doesn't work because iOS can't use CSS style modification filters so the companion filters for the CSS Style modification filters are not necessary and should be excluded.

In ultralist.txt I tried using the pre-processor directive as I follow the logic but it doesn't appear to work and get loaded properly into Adguard for iOS.

! Start Web Annoyances Ultralist Exclusion Sublists
!#if adguard
!#if env_mobile
!#include filters/adguard_app_ios_exclusion_filters.txt
!#endif
!#endif
! End Web Annoyances Ultralist Exclusion Sublists

Related to AdguardTeam/AdguardBrowserExtension#917

I need to investigate further to find out why the sublist is not being loaded on Adguard iOS compiled list when subscribed to Web Annoyances Ultralist in the 'Annoyances' section of Adguard.

[yourduskquibbles]

!#include sublist wrapped in invalid uBO directive adguard_app_ios in Ultralist.txt still fetches and loads the sublist that should be ignored because it is wrapped in invalid uBO directive adguard_app_ios

!#if adguard_app_ios
!#include filters/adguard_app_ios_exclusion_filters.txt
!#endif

In uBO the sublist should be ignored entirely but based on testing, logger shows the filters/adguard_app_ios_exclusion_filters.txt being fetched so additionally adding the !#if adguard_app_ios pre-processor directive within the adguard_mobile_exclusion_filters.txt sublist as well.

!#if adguard_app_ios
apnews.com#@#.header-placeholder, .optional-header-title
mobile.twitter.com#@#header[role="banner"] > div[style*="height"]
!#endif

[yourduskquibbles]

The uBO fix to recognize the directive adguard_app_ios (as well as additional special case directives) is now published with gorhill/uBlock@00b790c and is implemented with uBO 1.29.1b

[krystian3w]

How this works with something like:

!#if (!adguard_ext_android_cb && !adguard_app_ios)
!#include filters_uBO_AG.txt
!#endif

in file filters_uBO_AG.txt we found:

• :has()
• :has-text()
• :upward()
• many scriptlets, css filters
• html filtering
• many other embeded pre-procesor directives e.g.:
  • disable use css filters, if html filtering kill problem faster and still safe.
  • filters specified for disabled userCSS in Nano Adblocker for Chromium.

[yourduskquibbles]

!#if (!adguard_ext_android_cb && !adguard_app_ios)
!#include filters_uBO_AG.txt
!#endif

uBO only allows ONE preprocessor directive, no match for two cases with &&

[yourduskquibbles]

in file filters_uBO_AG.txt we found:

* `:has()`

* `:has-text()`

* `:upward()`

* many scriptlets, css filters

* html filtering

* many other embeded pre-procesor directives e.g.:
  
  * disable use css filters, if html filtering kill problem faster and still safe.
  * filters specified for disabled userCSS in Nano Adblocker for Chromium.

AdGuard has its own internal system that converts uBO syntax to AdGuard syntax, I don't think these filters get thrown out, just rewritten internally.

[krystian3w]

I mean, if I don't have to reprogramme this preprocessor, so that some 5 thousand filters won't suddenly disappear from the list of active filters in uBO, under AdGuard such exclusion works well for now.

AdGuard has a strange policy - filters do not for iOS / Content Blocker convert in CSS (instead use preprocessors):

example.com#$#.pop-up { display: none !important; }
example.com#$#body { overflow: visibile !important; }

So instead of adding thousands :style(display: none !important;) (when works simple example.com##.popup) I use one "big" preprocessor #if (!adguard_ext_android_cb && !adguard_app_ios)

[yourduskquibbles]

I've Added an Adguard App for Android exclusion list now

Discussion: AdguardTeam/AdguardFilters#63209 (comment)

Related: #67