Version 8 (modified by, 14 years ago) (diff)


WebKit2 - High Level Document

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.


WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic. In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. These techniques include:

  • Notification style client callbacks (e.g. didFinishLoadForFrame) These inform the embedder that something has happened, but do not give them the chance to do anything about it.
  • Policy style clients callbacks (e.g. decidePolicyForNavigationAction) These allow the embedder to decide on an action at their leisure, notifying the page through a listener object.
  • Policy settings (e.g. WKContextSetCacheModel, WKContextSetPopupPolicy) These allow the embedder to opt into a predefined policy without any callbacks into the UIProcess. These can either be an enumerated set of specific policies, or something more fine-grained, such as a list of strings with wildcards.
  • Injected code (e.g. WebBundle) Code can be loaded into the WebProcess for cases where all the other options fail. This can useful when access to the DOM is required. [Planned, but not currently implemented]

The major API classes are:


  • Encapsulates all pages related to specific use of WebKit. All pages in this context share the same visited link set, local storage set, and preferences.


  • Encapsulates all pages that can script each other.


  • Basic unit of browsing. Stays the same as the main frame changes.


  • Native view that hooks into the platform's toolkit. On Windows, this wraps a HWND. On the Mac, it inherits from NSView.

Port-Specific APIs

We plan to build a fully noblocking Objective-C API for Mac OS X as a wrapper on top of the C API. We believe a similar approach may be viable for other ports.

We are also not removing or obsoleting any of the existing port-specific APIs. WebCore will remain as-is, and all current APIs will continue to work and be fully supported. Thus, WebKit development and existing ports of WebKit will not be disrupted.

Process Architecture

WebKit2 changes the WebKit stack to build a process management mechanism inside the WebKit API layer.

Here is what the architecture of a traditional WebKit port looks like:


Everything is in one process, and there is an API boundary between the application and the WebKit API. This is a simple model, and typically it's pretty easy for applications to reuse the WebKit API.

Here is what we are going for with WebKit2:


Notice that there is now a process boundary, and it sits *below* the API boundary. Part of WebKit operates in the UI process, where the application logic also lives. The rest of WebKit, along with WebCore and the JS engine, lives in the web process. The web process is isolated from the UI process. This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multicore CPUs. There is a straightforward API that takes care of all the process management details for you.

How is This Different from Chromium?


There are two key subsystems that support the process division :

  • CoreIPC - an abstraction for general message passing, including event handling. The current implementations use mach messages on Mac OS X, and named pipes on Windows.
  • DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap.

There are two other important abstractions, which may be pushed down to WebCore or WTF over time:

  • Run Loops
  • Work Queues

Attachments (3)

Download all attachments as: .zip