Next haikuwebkit release


Haikuwebkit 1.9.3 has been released, it is available for r1beta4 for both architectures and the nightlies.

A short changelog

  • Revert back to the slower less flickering renderer
  • Implement loading of webfonts (beta5 / nightlies only)
  • Fix saving META:url attribute on downloads
  • Implement most CSS system colors (of css color module level 4)
  • Fix system buttons rendering disapearing on page scroll (NOTE: may still occur in slight cases, but should generally work now)
  • Implement system buttons responding to hovering over them
  • Use OS colors for the default HTML background, text color etc.
  • Updated to Webkit version 615.10.15

If you encounter new issues (or have some fixed with this release) feel free to create a ticket or update one on


I got it and it works fine.


Thanks to everyone involved in this release! :smiley: (I’m very happy, it is not just me this time)


I tried it out this morning, and it’s so much better. Thank you, all!


Excelent work to all involved in this release!!! :clap:


A Big thank you for

That makes pages with many picture and video frames more readable and enjoxable ! :slight_smile:

I just wanted to open a thread to thank you stopping this annoying flickering !.. :smiley:

… so this way I can spare this and just simple answering to this post :wink:

That’s what other fixes / enhancements in these 2 updates may bring tu us - users – still not so viewable for me – pardon me !.. :wink:

1 Like

I suggest to use this thread in to the future to give
– feedback
– and thank you as well

in case next HaikuWebkit releases.

Uff ! I spoke. \O/

Yay, I’m excited to try out the webfonts!!!


Great to hear about the new release overall - that I have yet to try myself due to a construction-damaged city level backbone fiber where I live :frowning: - but the above I think is a mistake, having made (and reverted) it myself just a few months ago as part of a web browser related project I was working on.

The short version of it is that there are quite a few websites out there that e.g. just blindly assume that the HTML background colour is always white, and do not set one themselves. This in turn means that if you - like me - set the default background colour to black, say e.g. inherited from a dark mode theme or simply on browser rendering level to reduce some kinds of page loading flicker, then there is a risk of some such sites/pages ending up being black text on black background… (wrt to the latter issue, what I did in the end was to set the background colour to black during loading of the page, then back to white upon finish, which seems to work well). IIRC, one such site was the then newly re-designed The Verge, however this was a couple of months ago so maybe it has been updated since (though probably not).

Thanks again!

and they are correct!

Which is why the background color is always light, even if you set a dark OS document color, unless the site supports dark mode.

If the website does not support the dark mode and your document color is in light mode haikuwebkit will instead pick a fallback light mode document background color. :slight_smile:

This works because of the prefers-color-scheme css variable.

In fact, some of this work was precisely to fix the issue you had aswell, since haikuwebkit was before using my dark controls on light mode sites, now it correctly uses light controls instead.

edit: you can also read the css spec i’ve linked above for that context


HTML5 supported features – status of toiday – in case Webpositive browser.

Against it …

For me now interestingly more hiatus is a feature rich adblocking solution that also prevents malicious/annoying links/pages and also advertising or phising/cheating objects.
As I used several different adblock solutions in different mainstream browsers I did not know how much they did keeping me from dangerous or stressing situations - when we use a browser without such defense.

Until it had not solved in Webpositive I can use it to read reduced content and not visit any link provided anyone else as I am here without any defense - even aganst MY stupidity when sometimes I take higher risks in a browser where fortunately I had AdBlocker. Fortunately as sometimes Adblocker is not so good as usual and some bad boys are remain unfiltered. I was experienced so and got some hit as well. Then MalwareBytes helped me out - so next time I rather waited till that page went back to safe again - after a week or two.

adblocking will come with webkit2, My current plan is to tackle that next (no promises :p)

Untill then, you can use dns based adblocking, for example the consolidated hosts file from Steven Black GitHub - StevenBlack/hosts: 🔒 Consolidating and extending hosts files from several well-curated sources. Optionally pick extensions for porn, social media, and other categories.


I’ve been using hosts file blocking for a long while now. Works very well.
For anyone that doesn’t want to mess with the hosts file manually, there’s “hblock” in HaikuDepot.


has not quite the same level as ublock origin though…

its a good starting point…

I find that these changes constitute a big improvement to Webpositve. Congratulations.


This new release is fantastic. First time I can fully use WebPositive here on the forums without rendering issues. I’ll use WebPositive as my default browser again.


hblock’s default filter blocks haikudepot, unfortunately.

HaikuDepot application and in web+ work here.
This is hblock’s issue tracker.


You can also use a host file from a linux distro that uses host files to block ads (ex Puppy Linux). I’ve been using one for a while, and it works quite well

1 Like

Thanks to this update, Mastodon and Discord (somewhat) work much better in WebPositive now!