feat(content-blocker): wire WKContentRuleList via adblock-rust on Apple#348
Open
theoden8 wants to merge 5 commits into
Open
feat(content-blocker): wire WKContentRuleList via adblock-rust on Apple#348theoden8 wants to merge 5 commits into
theoden8 wants to merge 5 commits into
Conversation
theoden8
force-pushed
the
claude/fix-ios-content-blocker-F3IBQ
branch
from
5ca22dd to
4c6b4e2
Compare
iOS/macOS WebViews were relying solely on the JS-bridge interceptor (Bloom + per-host roundtrip) for sub-resource blocking, which is slow under load. The Rust crate already exports the rules in Apple's JSON shape; this commit wires that output through InAppWebViewSettings.contentBlockers so WebKit blocks natively before the JS layer sees the request. Stats still come from the JS bridge — WebKit fires no callback when a content rule matches. Built once per ruleset (compute() isolate), cached on the service by content hash, paired with the fork branch that hash-keys WKContentRuleListStore identifiers so warm starts skip compilation. https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke
…purge Calling the adblock-rust FFI through compute() crosses an isolate boundary with a process-loaded DynamicLibrary, which is fragile and unnecessary — the conversion is single-digit milliseconds for a 30K-rule list, same pattern _maybeRebuildRustEngine uses. Run it on the caller's isolate. Add a CB-012 scenario for the stale-identifier purge that the fork companion commit added: WKContentRuleListStore would otherwise accumulate one bytecode entry per ruleset edit, indefinitely. https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke
Surface what's happening to the WKContentRuleList payload during a service rebuild and at every WebView attach so the in-app log viewer can confirm the path is wired up: rebuild entry with list / byte / hash detail, skip reasons (non-Apple platform, no cache, unchanged hash), payload-ready summary with rule count + duration, and per-webview attach messages tagged with siteId and identifier short-hash. https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke
The WKContentRuleList build path called inapp.ContentBlocker.fromMap on every rule emitted by adblock-rust. A single rule that tripped fromMap (e.g. a non-null bool field arriving as null) used to abort the entire payload build, leaving WebViews with no content rules. Wrap each per-rule construction in try/catch, count the casualties, and feed the skip total into the rebuild log so a stale fork pin (missing the fromMap null-default fix) surfaces clearly instead of "WKContentRuleList JSON export returned null" hiding the cause. https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke
"payload ready: 0 rules ($skipped skipped...)" was emitted at info level, easy to miss when other rebuild paths fire info around it. When the wrap rejects 100% (or >50%) of rules, log at error/warning and mention the most likely cause — a stale fork pin missing the ContentBlockerTrigger.fromMap null-default fix. https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke
theoden8
force-pushed
the
claude/fix-ios-content-blocker-F3IBQ
branch
from
4c6b4e2 to
836a139
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
iOS/macOS WebViews were relying solely on the JS-bridge interceptor (Bloom + per-host roundtrip) for sub-resource blocking, which is slow under load. The Rust crate already exports the rules in Apple's JSON shape; this commit wires that output through
InAppWebViewSettings.contentBlockers so WebKit blocks natively before the JS layer sees the request. Stats still come from the JS bridge — WebKit fires no callback when a content rule matches.
Built once per ruleset (compute() isolate), cached on the service by content hash, paired with the fork branch that hash-keys WKContentRuleListStore identifiers so warm starts skip compilation.
https://claude.ai/code/session_01CKn59eXGzJiqj38EfT53ke