Hacker News Reader

Comment by gcp | Hacker News Reader

You can have ad blocking, but you can't have the fast JavaScript engine and ad blocking, unless you are Safari. So you can't have a Chrome or Firefox with both, unless Apple fixes their APIs or allows the "real" versions of those browsers.

View on HN

Not true at all, and also nothing is stopping you from building your own ad-blocking logic in to your browser either - iCab Mobile for example does just that.

It's not possible to do that and use the fast JavaScript engine from WKWebView. I'm sorry but you have no idea what you're talking about.

Why not? WKWebView has a delegate callback for the policy to load any given URL. You can implement ad blocking that way. Or you can chose to inject CSS rules if that's your fancy.

What's the technical issue?

Are you referring to the `-[WKWebView navigationDelegate]`?

Thats only used for user initiated navigation, not loading of assets.

You could still inject a JavaScript file or CSS file though to help hide pieces of the view. But that would be content blocking after the HTTP requests have been made.

I don’t know of a way to intercept the HTTP requests as they’re being made from a WKWebView like Safari does for content blocking.

Could attach a service worker if it can load before the assets. I know safari has this under consideration, but it's a w3 standard now anyway.

Isn’t it still a working draft?

you're right, too soon.

The technical issue is that WKWebView does not honor any custom classes registered with NSURLProtocol (`NSURLProtocol registerClass:`) like UIWebView does, so you don't get to intercept/change/deny every request (not just top-level requests) that the browser makes.

Reply on news.ycombinator.com