Issue 5094 - Implement support for :has() in chrome extension

lib/filterValidation.js

Index: lib/filterValidation.js
===================================================================
--- a/lib/filterValidation.js
+++ b/lib/filterValidation.js
@@ -14,17 +14,17 @@
  * You should have received a copy of the GNU General Public License
  * along with Adblock Plus.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 /** @module filterValidation */
 
 "use strict";
 
-const {Filter, InvalidFilter, ElemHideBase} = require("filterClasses");
+const {Filter, InvalidFilter, ElemHideBase, ElemHideEmulationFilter} = require("filterClasses");
 const {Utils} = require("utils");
 
 /**
  * An error returned by
  * {@link module:filterValidation.parseFilter parseFilter()} or
  * {@link module:filterValidation.parseFilters parseFilters()}
  * indicating that a given filter cannot be parsed,
  * contains an invalid CSS selector or is a filter list header.
@@ -137,17 +137,19 @@ exports.parseFilter = text =>
 
     filter = Filter.fromText(text);
 
     if (filter instanceof InvalidFilter)
     {
       return {error: new FilterParsingError("invalid-filter",
                                             {reason: filter.reason})};
     }
-    if (filter instanceof ElemHideBase && !isValidCSSSelector(filter.selector))
+    if (filter instanceof ElemHideBase &&
+        !filter instanceof ElemHideEmulationFilter &&
+        !isValidCSSSelector(filter.selector))

[Sebastian Noack, 2017/04/04 10:14:45]

When we implemented CSS property filters we deliberately decided against
pseudo-class syntax, but to rather misuse attribute lookup syntax, e.g.:

  [-abp-properties="color: red"]

That way these filters not only pass the validation here, but even more
importantly, it doesn't cause any problems with older version of Adblock Plus
which aren't aware of the new filter syntax. Otherwise, if we implement :has()
with this pseudo-class syntax, it will essentially break element hiding on older
Adblock Plus versions, as soon as filter lists use it.

[hub, 2017/04/05 09:05:53]

ok. this will need to have changes in the adblockpluscore patch first.

[hub, 2017/04/05 13:18:43]

I suggest that we use something like:

[-abp-selector=':has()']

Basically the CSS selector is the value of the attribute '-abp-selector'.
This allow for a simpler syntax, easy to move forward when CSS4 is supported.

[Sebastian Noack, 2017/04/05 14:58:49]

This appears unnecessarily verbose (and potentially confusing) to me. Also it
will be inconsistent with CSS property filters, except we change the syntax for
them as well, but then we will have an unnecessary breaking change. How is this
any simpler than just going with [-abp-has=""]?

[hub, 2017/04/05 15:44:57]

How do you express ":has(:has(...))"? 

The idea was to have well formed selector as the attribute value. 
And when we implement :has-text(), it will be easy.

It also will make the transition to CSS4 easier.

[Sebastian Noack, 2017/04/05 16:08:28]

I see, nesting might become ugly, mostly because of quotes as far as I
understand. I guess, [-abp-selector=":has()"] is the way to go then.

As for CSS property filters, we should allow [-abp-selector=":properties()"] as
well then, but should also support the old syntax (i.e. [-abp-properties]) for
compatibility, at least for some time.

However, one thing I still wonder about, what if browsers implement :has()
and/or :properties() in the future, with different semantics than we provide?
Wouldn't it make sense, for this reason to prefix :has()/:properties() even if
we wrap them into [-abp-selector=""]?

     {
       return {error: new FilterParsingError("invalid-css-selector",
                                             {selector: filter.selector})};
     }
   }
 
   return {filter};
 };