iOS app 1.5.0 no longer allowing content blockers?

(Matt Sephton) #1

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!

3 Likes
(Penar Musaraj) #2

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.

2 Likes
(Matt Sephton) #3

Content Blockers can/do work with WKWebView if that’s what you’re using?

Also guess/probably doesn’t fill me with confidence.

(Penar Musaraj) #4

Yes that’s what we are using.

1 Like
(Matt Sephton) #5

I’ll see if I can dig up any info on whether there’s anything special needed

3 Likes
(Sam Saffron) #6

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?

iOS app 1.5.0 regression - external links always open in Safari
(Matt Sephton) #7

Not ads, no. Other things like buttons and menus I’d rather not see.

(Sam Saffron) #8

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?

(Matt Sephton) #9

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

(Jeff Atwood) #10

That’s annoying, have you opened a “site feedback” topic on that Discourse site to discuss better placement of that button on mobile?

1 Like
(Matt Sephton) #11

Of course. No dice.

So I just fix things like this myself. It’s easier.

Until now! :joy:

This is just one example; my blocker setup does so many I’ve lost count.

(Jeff Atwood) #13

It’d be better as an overlay maybe at the bottom left or something? Then it would not permanently consume screen space…

(Matt Sephton) #14

If it was my site, sure. But trying to persuade non-technical forum admins… :man_shrugging:

(Sam Saffron) #15

What about if you lobbied to remove it once a user donates? Should be very easy in a theme component

1 Like
(Matt Sephton) #16

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

(Penar Musaraj) #17

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.

1 Like
(Sam Saffron) #18

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

4 Likes
(Jeff Atwood) #19

It’s also better to fix it for everyone (e.g. deal with the source) rather than “fixing” it for advanced ninjas only.

2 Likes
(Matt Sephton) #20

This is correct, I did the same reading.

In terms of the different web view types honouring iOS Safari Content Blockers:

Ignores Content Blockers:

  • UIWebView
  • WKWebView

Honours Content Blockers:

  • SFSafariViewController

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. :sob:

Thanks all for your input.

Nice work on the new app though @pmusaraj @sam

(Sam Saffron) #21

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.