WKWebView provides no way to introspect what is blocked by the Block Rules.
This, firstly, makes it more difficult to debug rules, as we cannot be sure if a rule matches the intended url, or if a particular rule is too aggressive and matching too many urls.
Secondly, most browser using this feature like to include a counter to show how many requests were blocked on a specific page.
Currently, in Firefox and Cliqz, this is implemented by a UserScript that tries to collect urls from the document and re-match against a blocklist in the app (which is both inefficient and imprecise).
Introspection API would be helpful to detect the breakage introduced by blocking rules.
To be clear, you're asking for WKWebView API for this, for the embedding app, rather than exposing this to content blocker extensions?
Correct, our context is a privacy oriented web browser.
For example it would be useful to ask WKContentRuleListStore if the given URL will be blocked.
This is partially related to https://bugs.webkit.org/show_bug.cgi?id=152598#c9
Not sure how this would work for content blocking extensions. Perhaps Andrey Meshkov can provide some insights on it.
Well, if WKContentRuleListStore would provide a "checkRequest" method, we could benefit from this as well. For instance, we could add a simple "rule testing" tool right in the app.