![]() if the URL has any kind of query string (e.g. search = "" ) Īdd this, as a single line, to your user filters in AdGuard and any time you visit a Wikipedia article, you will be redirected to Wikiwand. org ^ $generichide, badfilter wikipedia. The full v4.5.1 changelog can be found on Github.Īny feedback is also very welcome in Github issues.|| wikipedia. We hope you'll enjoy improved AdGuard for iOS, and if you have any thoughts about this update, please don't hesitate to leave a comment below or reach out to us on social media. In DnsLibs (our DNS filtering engine) v2.3 update we have done some serious rework and adjustments which significantly improved AdGuard's DNS-over-HTTP/3 performance and stability.Īlso, some other things were fixed, one of them being the issue where AdGuard wouldn’t open on iOS 13.x. Scriptlets and TSUrlFilter are also nothing short of important, since they help implement the Advanced blocking feature in AdGuard for iOS. SafariConverterLib converts AdGuard filtering rules into Safari content blocking rules, so it basically makes possible to use the full power of our filters in AdGuard for iOS. efficient and up-to-date performance of blocking rules. The update of these three components and their interconnection helps maintain high filtering quality, i.e. For instance, we updated SafariConverterLib, Scriptlets, and TSUrlFilter dependencies. Thanks for letting us blow off some steam above, now we can tell you about nicer things in v4.5.1. SafariConverterLib, Scriptlets and TSUrlFilter updated So while everything should work fine for most users at the moment, we are very much looking forward to Apple fixing this bug ASAP. If a content blocker is still a little too big for iOS’s liking (the final size depends on how many and what filters are enabled by the user), we automatically cut its size so that at least part of the rules that meet the size requirement gets applied in Safari. It took us over a week to figure out a temporary measure: we restricted the size of our JSON files and optimized main filters so that they can squeeze into this new ‘size requirement’. Also, here’s the ticket ID in Apple’s Feedback Assistant: FB13282146. We’d appreciate it if you could upvote it there by pressing 'Me too'. Since it’s an obvious bug in iOS 17, we already reported it on Apple’s forum. This leads to a simple question to Apple: how come a 40k rule content blocker crashes when Safari officially allows 150k rules? It turned out that Safari wouldn't accept files over a certain size anymore - even content blockers with 40-60k rules (which is 3 times below the 150k limit) would sometimes crash, depending on the rules they contain. The contradictionĪll in all, we were faced with a surprising new reality where using our standard Safari content blockers with 150k filtering rules was all of sudden causing a crash on iOS 17. Currently, according to the Safari Content Blocking API documentation, it allows for up to 150k rules in one content blocker (and one app can have several content blockers). As you can probably guess, this is an indispensable tool for ad-blocking apps on iOS, because it gives a way to apply filtering rules to pages accessed in Safari. The next realization was that filters would still update successfully depending on the filters enabled (or, rather, not enabled) by the user, which in turn helped us find out that loading rules into Safari sometimes hits a memory limit - something we never had a problem with before.Īpple provides developers with the ability to implement Safari Content Blocker functionality in their apps, which allows them to offer content-blocking features to users. This detail and increasing user feedback lead us to realize that the root of the problem lies in the updated iOS. But the more we tried, the more we started to pay attention to the fact that the issue occurred only on the newest iOS, which is supposed to be the most polished and optimized. Initially, we were trying to find issues in our own app's code (as any responsible developer would). In some cases, however, this sight would come to an end in the form of filter update errors. Yeah, you heard that right - tapping □ icon in the upper right corner of the AdGuard's main screen was triggering an endless spinning animation but nothing happened. So, it all started with us trying to find a solution to an issue on iOS 17 where filters would just update endlessly without actually updating. Apple, you said we could use up to 150k content-blocking rules in Safari, what happened? The issue Apart from the bug workaround, this release also contains some nice improvements and fixes beneficial to the app's performance and stability. This update comes with a story, since we found an unexpected iOS 17 bug that essentially limits the number of content-blocking rules, so you already know there’s no way we aren’t telling you all about it.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |