> Good luck with using that “equivalent” in an embedded web view.
It works, so thanks. Maybe you're referring to the impossibility to access the plugin's settings from the embedded web view. But if it's a site you've visited before and configured to your preference, then it takes effect in the same way there as in full FF.
> iOS content blockers tell Safari what to block and don’t have access to where you go.
If I tell it 'block scripts from example.org on news.ycombinator.com' then it's a pretty good bet that I visit news.ycombinator.com.
Right, I realise iOS content blockers aren't that powerful, so it's hypothetical. ;)
I don't know, I'm just reporting my experience as a user. I don't develop for Android or know anything about what Mozilla says about it.
Feel free to reproduce it yourself: block third party by default (for example), open some broken page, observe it as such; 'open in browser' from 3-dot menu; amend settings to allow whatever it needs; back out, observe it functional.
Open in the browser is not the same thing as an embedded web view. Take something like an RSS reader. You click on the link and it shows you the web page inside the app without taking you outside of the app.
It works, so thanks. Maybe you're referring to the impossibility to access the plugin's settings from the embedded web view. But if it's a site you've visited before and configured to your preference, then it takes effect in the same way there as in full FF.
> iOS content blockers tell Safari what to block and don’t have access to where you go.
If I tell it 'block scripts from example.org on news.ycombinator.com' then it's a pretty good bet that I visit news.ycombinator.com.
Right, I realise iOS content blockers aren't that powerful, so it's hypothetical. ;)