[GSoC 2024] Fixing the crashing | Haiku Project

Yes, but webkit uses EGL for OpenGL, if you can‘t use it you might have to try and make it use HaikuGl instead. Not sure how much worl that is : )

That’s the hard part with OpenGL. Once you have that, the OpenGL APIs are standard and just work. And our implementation is Mesa, like everyone else’s.

EGL is an attempt to standardize that part. If you don’t use it, you will have to write custom Haiku code with BGLView instead. Previously, WebKit could use glx, which is the X11specific way of doing the context/window creation. But now, it’s egl-only for Linux (allowing things to work on Wayland, and maybe even DirectFB if that’s still a thing).

So, yes, if we go with OpenGL, using EGL is likely a good idea. But then we have to make it work on Mesa side.


This EGL issue in Haiku, which needs to be fixed:

So, make it work, even with the bugs. At the very worst, the trail through the jungle is beaten and others can start pitching in to get it working fully.

1 Like

Progress! No more crashing!

Well, at least as long as a window (Tracker in this image) doesn’t get moved onto MiniBrowser.

Technical details

This time, it was just a one line fix. WebProcess tried decoding an integer from a message. Normally, it would just decode the integer directly. But Haiku’s port specified that the integers should be treated specially, as a message attachment. Well, we don’t use message attachments, and, as you can guess, this mistake eventually led to a crash.

The fix: Haiku doesn’t use attachments atm, so just make the attachment type the closest thing to nothing: an empty struct. Now no more integers will be confused as attachments!


It appears someone has been putting some work into directfb… but I’d say its in the solidly avoid terretory. Maybe they are maintaining it because they have legacy devices or something to support? https://directfb2.github.io/

Now I can cover it all I want. The problem was calling something from the window thread which should have been called from the main thread. (PR)

MiniBrowser is now sufficiently stable that I can move on :tada:. I still can’t resize it or exit it without crashing, but good enough for now.

Now I wonder what is needed to get a web page displaying…


Nice work @Zardshard ! :+1:


The three processes need to talk to each other. If tey can’t, not a lot will happen.

I recommend that you use devconsole - Gitiles (git clone https://pulkomandy.tk/gerrit/devconsole) and enable logging (using the appropriate environment variable for WebKit), since a lot of the logging is sent to DevConsole (this allows to get the logs from all three processes in a single place, with highlighting of which logs come from where).

The general idea is that the browser (the “UI process”) creates a “connection”, and forwards each end of that connection to the web process and the network process when starting them (through command line arguments). The two processes should then be able to talk to each other.

The generic UNIX version of WebKit (used for GTK and WPE ports for example) uses UNIX domain sockets for this. In the current Haiku code we try to use BHandler/BLooper, but that doesn’t work great, because you can’t create a BMessenger (that would be the logical thing to use as a “connection” object) which targets a process that isn’t started yet.

So, there are two options, either figure out a way to make this work using BMessenger (Rajagopalan had implemented something using a temporary hashmap in the UI process allowing to create the “real” BMessenger after the processes had started, but it wasn’t clean and a bit hard to follow). Or, we could switch to UNIX domain sockets as other UNIX ports do, but I’m unsure how convenient this will be if the processes also have to run a normal BLooper event loop (which is how it’s done so far).


Already have this :slight_smile:

Yes, that seems to be part of the problem. Here’s what I know so far: The InitializeWebProcess and InitializeNetworkProcess messages get through. So MiniBrowser appears to be able to communicate with WebProcess and NetworkProcess. WebProcess then sends a GetNetworkProcessConnection to MiniBrowser, but MiniBrowser doesn’t receive it.

1 Like