For DNS blocking, configure your home router to use the config provided by NextDNS. This would block adverts (and known malicious domains, but you’re in control as to what you block) for all machines on your network. NextDNS has good tutorials and example configuration for a variety of devices. And if something is blocked that you’d like not to be blocked, it can be whitelisted.
3 Likes
it is a method that worked in the early days with rooted Android, so much so that then I started using it on linux and windows …
AdAway adblocker creates a host file with all the various lists that are updated from time to time via the web, maybe it could be adapted to work quickly for HAIKU…
hblock does exactly this, and it is already in the depot.
4 Likes
thanks I was not aware of that
EDIT:
i immediately did some tests:
i installed hblock i ran it on the shell, and created a hostfile which is now 7 mb, i also restarted haiku, but it seems that web+ does not block ads, nor those of duckcduck go, nor those of youtube, I just did these two quick tests, maybe I missed some steps?
Thanks for the hint to install Font Awesome as system font.I already did that with Noto Color Emoji so that Otter shows them but I would have never come to the idea to install icon fonts to solve that problem…
For the hosts file blocker: I know that solution but I maintain my own list of stuff I want to block (mainly all Google bullshit because it’s a disgusting data-kraken nobody needs) and I can easily do that with a wildcard entry in a Adblock-Plus-formatted list but I would have to specify every single subdomain they have (and that’s likely millions) in the hosts file or run a own DNS server that serves the block on a wildcard domain.
2 Likes
Even with an adblock of some sort client-side it will still take away some system resources to process. Doing it from the network level is where I would recommend starting for others. Either using a 3rd party DNS service or setup a small pihole and let it do its job.
1 Like
Is it enough to install fontawesome via HaikuDepot to make it system wide?
I do not see them in: system/data/fonts
system/non-packaged/data/fonts
nor in:
/boot/home/config/non-packaged/data/fonts
after installing with HaikuDepot.
Do I have to restart?
Which website I can test for fontawesome?
1 Like
No packaged data will ever show up in the non-packaged tree. Look in the normal paths. If it is still missing: reboot.
They are installed in /system/data/fonts/ttfonts/fa-*.ttf
On that note ttfonts is correct? I would expect ttffonts?
1 Like
ttffonts would mean true type fonts fonts, which is wrong. ttfonts is true type fonts.
Thanks for explaining, didn’t check other OS’s about this, was just wondering because the extension of the fonts is ttf
.ttf => dot true type font, seems fine to me.
You can start by this forumas it was one of the reason why font awesome was packaged. For example, IIRC, the magnifying glass on top bar is not rendering in most fonts.
It’s rendering fine for me, It’s proabably in noto symbols 2 or noto symbols
Ok reboot did the trick, thx all for help and info.
Webpages lokking the same, all render is ok!
1 Like
What I find important is that the current version of WebPositive allows me to use this forum rather well. There are some visual glitches, such as the header bar jumping around while scrolling, some screen tearing during scroll and the loading spinner looking really odd, but overall nothing that prevents me from browsing and using the forums. I’m rather pleased with the current version of WebPositive 
7 Likes
The current build of WebPositive is the fasest browser that I use, including browsers on different OS’s. It is just running circles around them.
I do have an occassional crash on various web sites but not like I use to, prior to using a modified host file.
I don’t think I have seen a ticket about the header, on Safari it isn’t correct either, but only by one pixel. I suppose this is fixable.
Should be css anchor fixed or something?
We fixed some crashes on nightlies recently aswell, one for media playback and one for wasm… It’s slowly getting better, or well more stable
1 Like
It’s not generally off. Looks to me like a general rendering performance issue with fixed position elements. While scrolling the header starts flickering, always scrolling a few pixels before jumping back to position. I can try to get a minimum layout that reproduces the issue.
I’m running daily builds of Haiku in qemu. Quite possible this is less noticeable on a better performing system or release build.
I think the problem is that the scroll optimization that just copies pixels down or up occurs separately from the re-render, which happens later, and so for a period of time, the copied pixels are all that you see. I think there was an attempt to fix this before, but it just caused more problems, and nobody has revisited it since.
4 Likes