1801554 - Refactor `declarativeNetRequest` `RuleCondition` into a set of classes and keep `RuleCondition` as sugar to them

Status: RESOLVED INVALID

(WebExtensions :: Request Handling, enhancement)

Description

[KOLANICH]

RuleCondition provides limited opportunities to optimize rule matching for the developers. Its meaning is to be a predicate, but its components are joined via logical AND operator and don't allow to provide alternatives within the same rule. It'd cause exponential growth of number of rules if it is needed to match requests with values from certain sets.

The proposal is to replace RuleCondition with CompiledRuleCondition object and predicate arrow functions taking as arguments the relevant queries objects. The only allowed AST nodes within these functions are

• returns of boolean values
• boolean operations on boolean values
• === and == operations, == is considered the same as ===
• Set.prototype.has , Map.prototype.has calls with string and integer arguments, also checking presence of strings as keys of objects that are not special
• accesses of properties of request objects
• String.prototype.substring calls
• String.prototype.indexOf calls
• String.prototype.match, RegExp.prototype.exec calls
• calls of other arrow functions matching the criteria with arguments matching the criteria.

Loops and recursion are disallowed.

All string properties of the request object returning values from a certain set become integer enums.

When the CompiledRuleCondition ctor is called:

• all the objects used within the matcher arrow functions are copied (not necessarily really copied, but the meaning is that their values used for compilation cannot be mutated)
• the matcher arrow function AST is verified taking into account types of each variable and property
• the matcher arrow function is compiled into native code

RuleCondition becomes syntax sugar for initializing CompiledRuleCondition with an arrow function doing the job and some accessor properties for compatibility.

CompiledRuleCondition second optional argument is debug, allowing to get a trace of the control flow graph path within the matcher function.

Comment 1

[Rob Wu [:robwu]]

If you want to use JS to evaluate conditions, use the webRequest API.

What you're describing here is an API that makes such firm assumptions on the evaluation, that it's difficult to optimize that in a generic way.
FYI: While still not as expressive, Chrome attempted to design a declarative webRequest API before (declarativeWebRequest, but dropped that because it's not feasible to optimize it in a way that the current DNR API allows for.

As my advice on DNR feature requests/solutions from bug 1801549 (https://bugzilla.mozilla.org/show_bug.cgi?id=1801549#c1) also applies here.