Bug 205720
Summary: | WKUserContentController Block rules introspection | ||
---|---|---|---|
Product: | WebKit | Reporter: | Krzysztof Jan Modras [:chrmod] <krzysztof.modras> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | achristensen, am, krzysztof.modras, mcatanzaro, mjs, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 13 | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
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.