Add ext_ubol for !#if condition
Issue Details
Please add the directive which only applies to uBOL and not uBO. I did https://github.com/AdguardTeam/AdguardFilters/commit/6b6e84cf3792f34d165eab258681db732231919e and https://github.com/uBlockOrigin/uAssets/commit/4d44dbede108488b40bf1c41a150793b7650518b, but think the rules may be a bit risky if used outside Japan. Supporting the directive allows us to keep them in the Japanese filters.
Proposed solution
Described
Alternative solution
~~env_mv3 for AdGuard MV3 extension and uBOL will also work. There may be a situation this is more convenient, so consider supporting this too.~~
Maybe the directive should be used alone and reserved as is in uBO version of filters so uBO/uBOL will just interpret it (as already supported). So AG can interpret it just like ext_ublock in practice except that it should not be removed in Filters Compiler.
@Yuki2718 This is not applicable to CoreLibs products since they does not define ext_ variables.
Sorry, please move to any appropritate place. But now I think, maybe this is not an issue if Filters Compiler leaves !#if ext_ubol ~ !#endif inside !#if ext_ublock ~ !#endif as a mere comment.
@Yuki2718 Sorry I don't know what appropriate place for this task because I don't understand what is it about.
Like adguard extension has ext_ublock is precompiler directives, and you want to add another? Or is it related to FiltersCompiler?
Yeah, I mixed up two issues. The one is I simply want another directive of ext_ubol, but then I wonder how AdGuard filters for uBO will handle the directive, and this is the another issue.
@Yuki2718 Please also write here It seems it must be handle
AdGuard supports matching both known and unknown directives. Apps only define adguard, adguard_app_windows (or mac/android), and cap_html_filtering.
I'm closing this issue since there is nothing to do from CoreLibs side
All right, will open an issue in FiltersCompiler.