Notes on WebKit

WebKit is an open source Apple-led browser engine project that powers Safari and Epiphany, as well as being the original basis for Google's Blink engine. It is notably portable, powering platforms such as automotive displays, game consoles, and more.

Unfortunately, WebKit documentation is fairly sparse -- especially when it comes to creating a "platform" that embeds WebKit directly. Therefore, most open source embedded WebKit projects (such as the headless browsers listed here) choose to use the existing GTK+ or Qt backends instead of using WebKit itself directly; this introduces additional dependencies, and makes it more difficult to port WebKit to platforms with fewer resources or library availability.

Documenting the WebKit API will hopefully make it easier to port WebKit to weaker/vintage platforms, and also create a better understanding of what's going wrong when things inevitably go wrong...

Architecture

WebKit is actually not the browser engine itself. Rather, WebKit is a frontend API that brings together WebCore (the rendering/layout engine) and JavaScriptCore (the JavaScript runtime) under one umbrella for browsers/platforms to use.

As a note, there are actually two WebKit APIs. WebKit2 (now usually referred to as just "WebKit") is the current, "modern" API, with features such as multi-process rendering, sandboxing support, and more. The old API, which used to just be called "WebKit" is now called "WebKitLegacy". This is a more "classical" browser engine that runs in a single process and has little to no support for modern browser sandboxing features. It's kept in the tree, but I believe it's deprecated.

Modern ports (such as WPE or WebKit2GTK+) use the WebKit2/WebKit API. To avoid confusion over naming, this page will refer to the modern API as "WebKit2", and the older API as "WebKitLegacy" to avoid ambiguity.

Where does WPE factor in?

Igalia is an open source consultancy firm that is one of the primary non-Apple contributors to the WebKit codebase. Most notably, they maintain the WebKit2GTK+ port, as well as WPE.

WPE can be considered a "meta" or "hybrid" platform. Rather than targeting a specific UI toolkit or platform, it instead acts as a sort of shim on top of libWPE, which itself is a stripped back WebKit API. libWPE can target multiple backends, similarly to full-fat WebKit, and it's intended for use mostly in embedded applications, such as automotive displays or kiosks.

WPE only has a few hard dependencies by design. The most notable and largest of these is EGL (meaning WPE does require a "real" GPU running on Linux or (maybe) BSD).

How do we add a new platform?

With great difficulty. WebKit's build system is old and large. Most of the build system is CMake, but there are also various Perl, Python, and Ruby scripts thrown into the mix gluing various things together (most notably the Perl scripts that manage WebKit developer builds). This means that adding a new platform involves writing a total of about a dozen CMake scripts, modifying the Perl scripts, and figuring out which build system options and configuration #defines are needed in order to get the platform working. There is some limited documentation on this on the WebKit wiki... but it's mostly undocumented. This is where the most work will have to be done.

JSCOnly is a "platform" with a minimal setup that just builds JavaScriptCore and nothing else. This is often cited as an example to look at when creating a new platform. However, WPE is also likely something to look at, as it includes an actual renderer. This may help provide a better indication of what needs to get done.

Where are we right now?

At the moment, User:Kraaabs has managed to build the WPE port, the libWPE Wayland/FDO backend, as well as cog, the "reference" WPE frontend. Next steps are:

• Try to create an alternative backend for WPE. There is an x11 backend in the tree, but it's broken right now. Can a simple SDL2 backend be created so that we can use WPE on non-Wayland platforms?
• Decouple EGL from WPE. This could either be a lot of work, or fairly easy. Currently I think we can probably copy WPE, rip out the renderer, and replace it with the Cairo renderer that many of the other ports (including fellow Igalia port WebKit2GTK+) use already. This would provide us with a software rendering option we can use with libWPE... as it stands, I don't think creating a platform from scratch is feasible with a small team, so targeting WPE is smart.
• If decoupling EGL is not feasible, and we DO have to write our own backend, EAWebKit (see below) may be a good reference point (it uses a Cairo based renderer, etc).

Other interesting WebKit platforms

User:Vmlemon has helpfully uncovered a few commercial WebKit backends from throughout history that may be useful resources to look at as far as creating our own platform:

• EA WebKit - EAWebKit is used in various EA games for embedded UIs/login screens/what have you. A very clean Cairo-based backend, and a very small codebase. Could be a great resource.
• PS3 WebKit - As used in the PS3 web browser.
• Blackberry WebKit - As used on pre-BBOS 10 based Blackberry phones (Olympia platform). Could be interesting for future projects...
• Nintendo WebKit (NetFront NX) - A variant of Access Co. Ltd.'s WebKit platform NetFront NX, as used on the Wii U, Switch, and 3DS. (update: doesn't actually contain any 3DS/Wii U/Switch modifications...?)
• PS Vita WebKit - Another Sony WebKit variant, for the PlayStation Vita.
• Nokia S40 WebKit - As used in the browser for Nokia S40 phones. Previously lost, was recovered by vmlemon from an old hard drive.

The commonly held belief is that the Sony WebKit variants are also Access Co's NetFront. This appears to be false (at least for the PS3 and Vita variants). These variants contain Sony copyrights, not Access copyrights like the other NetFront NX-based stuff. (Not that that makes much difference. See below.)

NOTE THAT THESE WEBKIT VARIANTS ARE FREELY DISTRIBUTABLE/MODIFIABLE UNDER THE LGPL!

What makes NetFront NX different from regular WebKit?

Nothing at all! NetFront NX is literally just renamed WebKit. Nothing has changed except the branding. I'm thinking it's more of a "service" than a "product".

See also

EAWebKit