205720 2020-01-03 05:42:47 -0800 WKUserContentController Block rules introspection 2021-05-28 07:41:57 -0700 1 1 1 Unclassified WebKit WebKit2 Safari 13 Unspecified Unspecified NEW InRadar P2 Normal --- 1 krzysztof.modras webkit-unassigned achristensen am krzysztof.modras mcatanzaro mjs webkit-bug-importer oldest_to_newest 1602396 0 krzysztof.modras 2020-01-03 05:42:47 -0800 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. 1602720 1 webkit-bug-importer 2020-01-03 20:22:15 -0800 <rdar://problem/58312877> 1620600 2 mjs 2020-02-19 02:41:43 -0800 To be clear, you're asking for WKWebView API for this, for the embedding app, rather than exposing this to content blocker extensions? 1620609 3 krzysztof.modras 2020-02-19 03:08:33 -0800 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. 1620617 4 am 2020-02-19 03:28:22 -0800 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.