Users are discussing the iOS app update 1.5.0, which no longer allows content blockers. gingerbeardman mentions that content blockers were working well in the previous version of the app but stopped working after the update. pmusaraj explains that the app switched to a webview in the latest update, which isn’t aware of content blockers.
gingerbeardman points out that content blockers can work with WKWebView if configured correctly. However, sam and pmusaraj mention that implementing this feature is not feasible due to bandwidth constraints and potential issues with ad revenue.
The discussion also touches on the topic of fixing issues at the source, rather than relying on content blockers. codinghorror suggests that trying to persuade site owners to make changes is a more effective use of time.
The issue is moved to #feature request by sam, but it’s unlikely to be implemented soon. gingerbeardman expresses disappointment that this feature was not considered before the 1.5.0 update and mentions that it’s a painful regression.
I use content blockers to improve my web experience. This includes hiding page elements and images, and blocking some styles and scripts.
This worked well inside the Discourse Hub app, until the recent 1.5.0 update (the one with the new SSO process).
What has changed regarding content blockers?
Can content blockers be allowed once again?
Thanks!
Interesting, we switched to a webview in the latest app update and I guess it isn’t aware of content blockers. And it probably can’t be made aware of them.
Content Blockers can/do work with WKWebView if that’s what you’re using?
Also guess/probably doesn’t fill me with confidence.
Yes that’s what we are using.
I’ll see if I can dig up any info on whether there’s anything special needed
hmmm but all non Discourse sites are still opened in Safari.
So this would be just about blocking ads on Discourse sites you are passionate about?
Not ads, no. Other things like buttons and menus I’d rather not see.
Can you expand on this with a few before / after pics, very curious to see what you are doing?
Is this on a site you control or do not control?
Sure thing.
Here’s an example where I block an image/button that has been placed in a way that breaks the page layout - urgh. I don’t control this discourse site.
Safari
Discourse 1.5.0
That’s annoying, have you opened a “site feedback” topic on that Discourse site to discuss better placement of that button on mobile?
Of course. No dice.
So I just fix things like this myself. It’s easier.
Until now! 
This is just one example; my blocker setup does so many I’ve lost count.
It’d be better as an overlay maybe at the bottom left or something? Then it would not permanently consume screen space..
If it was my site, sure. But trying to persuade non-technical forum admins… 
What about if you lobbied to remove it once a user donates? Should be very easy in a theme component
This is just one example. I can’t lobby for all of the blocker changes I have set up.
Plus, they were working before 1.5.0
The app doesn’t specifically disable content blockers, and if there is a way to have them work in WKWebView, I’d love to hear it.
I think there is an interface that accepts the same json safari does, but I am not sure if we can query it for the current list
That said I feel this is a mega advanced ninja feature I do not think we have that much bandwidth to work on it
It’s also better to fix it for everyone (e.g. deal with the source) rather than “fixing” it for advanced ninjas only.
This is correct, I did the same reading.
In terms of the different web view types honouring iOS Safari Content Blockers:
Ignores Content Blockers:
Honours Content Blockers:
There are a bunch of apps on the App Store that let you try them all here’s one
So it looks like I’m sadly out of luck on this with the new direction the app has taken. 
Thanks all for your input.
According to 150479 – Expose public APIs for content filters Firefox have an API they consume.
Can you test if your content blocking works as expected on Firefox / Chrome iOS? If so I am not against having a quick look at this next major app release.
We do not have the bandwidth to look at this for a while though.
