| > Curious why you'd want safari's content blockers to run inside chrome or firefox though? Because WKWebView has such a limited API that it currently is impossible to implement content blocking. WKWebView is both a blessing and a curse for browsers like Chrome and Firefox. A blessing because tt works really well inside that square area where content is rendered. It is as fast as Safari, as responsive to touch gestures, supports web APIs pretty well. A curse because the API that it exposes is completely lacking. No way to intercept network requests, no way to interact with the DOM, no way to interact with JavaScript, no way to customize it fully, no way to do proper session store/restore, no way to interact with its internal caches, no way to set the cookie policy, no way to customize the context menus that it exposes, no way to handle errors better, no way to set headers on requests, no way to use content filters .. I can go on for a while. You can look at the Chrome and Firefox source code to understand the crazy workaround both browsers had to do to get some pretty basic functionality. Search for WKWebView on https://bugz.webkit.org to see what people have been asking for, for the past three years. |