HaikuWebKit development thread

I’ve started looking into the HaikuWebKit framework and thought this thread could be a good place to collaborate. I’ve downloaded and tried to compile HaikuWebKit. I made it all the way through JavaScriptCore but inside the Haiku-specific code in WebCore I ran into multiple instances of a single issue.

Since WebKit is compiled without runtime type information or exceptions, dynamic_cast doesn’t work. In the instance of LLVM, which is also built without RTTI, there is a dyn_cast template that replaces dynamic_cast without needing type information at runtime at all. It uses compile-time constants. I just wanted to make a public note of this because I know that there are difficulties with WebPostitive and I wanted to help.


Ref: haiku/haikuwebkit: Official Haiku fork of the WebKit repository (github.com)

Ensure you do a few things:

  1. Use Haiku hrev56578-4 or higher.
  2. Install all mentioned package dependencies for HaikuWebKit build.
  3. Execute: “Tools/Scripts/build-webkit --haiku --no-fatal-warnings”

See how this goes. I recommend having 4GB (32-bit) or 16GB (64-bit) of available memory for multitasking build environments.

1 Like

As for me: I can be reached much better on irc.

If you open tickets against haikuwebkit (kits/webkit) on the bugtracker usually pulkomandy, madmax or me will answer there.

Also, thanks for helping out, if you have questioms about the code in haikuwebkit I might be able to help you, feel free to ask me :slight_smile:

No problem. My old crate has 32 GB of DDR3. I didn’t need to touch swap space on my initial build using CMake.

HaikuWebKit is compiled with RTTI enabled to avoid this problem. Did you get the sources from github.com/haiku/haikuwebkit?
Did you follow the instructions in the README to build it?

Yes. Or at least my fork of it.

No. I just used CMake the first time and @cocobean 's instructions earlier in this thread.

This time it almost made it. It couldn’t find the gcrypt header but has gcrypt as an active package.

You need gcrypt_devel for the headers, is that installed too?

It’s not listed in HaikuPorts. I’m going to look there next. I’ll have to try using HaikuPorter also.

It’s clearly there (libgcrypt_devel): Haiku Depot Server

If you are using the haikudepot app to install packages, you need to enable development packages which are hidden by default.

Oh yeah! I’m working from a fresh install so I forgot that my copy of HaikuDepot still had the safeties on.

Ok. It built now.


If WebKit_GTK is up-to-date and using the latest Linux version of the user-interface, would it be any less work cherry-picking changes from there to HaikuWebKit or would it make any difference? According to the documentation in HaikuWebKit, the last attempt at making Web+ multi-threaded was in 2019. I like the idea of being able to test on a working browser and eliminating dependencies one by one rather than chasing a moving target from behind.

all the code that is in webkitgtk is already in haikuwebkit. What do you mean by cherry picking changes?

Does that mean that Web+ uses GStreamer already? Does that mean that Gnome Web can be adapted to MediaKit? Personally, I think being able to cross-check against both versions would be best to reveal bugs in one that’s not the other.

No, it doesn’t. webkit is a cross platform project, the code to use this stuff exists but haikuwebkit is not wired to use it. why would we use gstreamee for example when webpositive can access the media kit which already uses ffmpeg?

You didn’t get the joke. I switched the MediaKit and GStreamer support to the Linux port and the Haiku port respectively, but it was supposed to be an example of an interoperability stress test for the code base.

Haiku is becoming an operating system of API wrappers so making a MediaKit wrapper for GStreamer headers might nullify the point of the argument, but leveraging ports for starters and then reducing out redundancy in the OS and apps over time was the development strategy. Of course making wrappers for APIs that aren’t commonly used or are too system-specific to be ported, doesn’t make sense either, which is why I asked.

if gstreamer doesn’t have a haiku backend already one could be added, that sounds easier than trying to maintain abi compatibility to foreign software.

In any case, haikuwebkit can be adjusted to use more common linux stuff, and this would make it easier to upstream. But the downside is that we loose system integration.

Even if we were to use a foreign drawing system it would make more sense to me to only use it for webkit atleast and leave gtk out of it, otherwise we get into the wierd situation that haiku provided haikuwebkit in the base install that depends on gtk.

anyhow: if you want to work on webkit2 support you are free to use curl, a foreign renderer, gstreamer etc. we can always see to later use our more native stuff instead, after webkit2 atleast works for us : )

and yes, webkitgtk running on haiku will probably be great to test against. But I’d rather not use it as my everyday browser : p

1 Like

It’s not so easy. GStreamer is based on GLib event loops and not BLooper. Mixing GLib and BLooper event loops in the same software is not easy, and in the same thread, nearly impossible. And WebKitLegacy is a single-thread design for the most part.

Also, this would mean every install of Haiku would need to have GStreamer installed, which means it would also have GLib and many other libraries. That would be a failure of what we try to do with Haiku: providing a consistent set of core system libraries, designed by the same people, and which can be used together easily. If we fail at that, we just become a bad Liunx distro who for some reason is using a different kernel to run exactly the same software as all other Linux distros. Is that what we want to be?

We already have a native haikuwebkit. It’s a different thing to have a port of something until we get a native option, but now we’re talking about deprecating the native option to replace it with a port. Why not just fix the native thing instead? It can’t be that hard?


Thanks for your explanation, @PulkoMandy , I’m beginning to see how involved this is.

For Webkit2, I put the info here on my build on Haiku:

About four files need reworking for R1B4 as they are based on the outdatedr APIs. I got 98% compilation otherwise…