Bug 205720 – WKUserContentController Block rules introspection

• Status: NEW
• Component: WebKit2

[Krzysztof Jan Modras [:chrmod]]

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.

[Radar WebKit Bug Importer]

<rdar://problem/58312877>

[Maciej Stachowiak]

To be clear, you're asking for WKWebView API for this, for the embedding app, rather than exposing this to content blocker extensions?

[Krzysztof Jan Modras [:chrmod]]

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.

[Andrey Meshkov]

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.