This page gives an overview of the [WebKit port](​https://github.com/haiku/webkit), how it's done, where the useful sources are, etc.

Build instructions are in the repo README so I won't talk about it here.

There are two "versions" of WebKit called WebKiLegacy and "WebKit" or WebKit2. The former is a single-process architecture, where the whole browser is a single application. The latter is a multi-process system, where the browser is just a shell, and there are WebProcess (html parsing, etc) and NetworkProcess (http requests) programs running in the background to do the actual work, providing some sandboxing. Haiku is currently using the former, work is ongoing (in the webkit2 branch) for moving to WebKit2.

Source layout

The sources for WebKit are in the Sources/ directory. There is also a Tools/ directory where you will find HaikuLauncher, the minimal browser used for testing, as well as other tools for the unit tests.

The Sources are split in several directories (lower to higher layer):

• WTF is the low-level platform abstraction. It provides threads, shared memory, etc
• JavaScriptCore is the javascript engine, which can be built standalone as the jsc executable.
• WebCore is the actual code of the web engine, including the HTTP request system, HTML parser, CSS interpreter, etc.
• WebKit is the WebKit2 code, with the main() function for the different processes, the communication channels between them, etc.
• WebKitLegacy is the "legacy" single-process code.

All of these (maybe except JavascriptCore) have some amount of platform-specific code. In WTF, for obvious reasons. In WebCore, for all the HTTP request (soup, curl, haiku, ...), rendering (cairo, freetype, ...), and any other platform specific things at this level. In WebKitLegacy and WebKit, for the APIs exposed to application willing to embed an HTML view or the like.

So, the main directories for the Haiku-specific sources are: Source/WebCore/platform/graphics/haiku ; Source/WebCore/platform/network/haiku ; Source/WebKitLegacy/haiku . There are a few additional files and in some cases specific code in files shared between platforms.

Philosophy of WebKit porting

There is usually little subclassing. Usually, a single .h file defines the API and each platform has the matching .cpp file implementing it. This means the .h may need to have some per platform #if when there are fields or methods specific to one or another platform. The idea is that this saves vtable overhead when there is going to be only one implementation compiled in.