Apple's WebKit2 will add Google Chrome-like split processes to Safari

A new framework for the WebKit open source Web browser layout engine was revealed Thursday, bringing with it a built-in "split process model" that will keep Web content such as JavaScript, HTML and layout in a separate process in browsers such as Apple's Safari and Mobile Safari.

Patches for the new WebKit framework, dubbed "WebKit2," are due to be released shortly, according to Anders Carlsson, who works in Cupertino, Calif., on Apple's Safari browser as well as the open source WebKit engine. In addition to Safari, WebKit also powers the Google Chrome browser, the Android Web browser, and Palm's WebOS.

"WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process," wrote Carlsson. "This model is 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 to use it."

In this method, each tab within a browser is "sandboxed," or existing in its own space. In essence, this means each tab is like its own separate browser. While Chrome currently does this in its own proprietary way in its WebKit-based browser, building the capability into the framework of WebKit2 would allow other WebKit-based browsers — including Apple's Safari — to employ this same technique.

Documentation accompanying the WebKit2 release noted that one goal for the new framework is to create a stable, non-blocking application programming interface. That would allow an unlimited number of threads to call an API at once, making the browser more flexible. This would be achieved, the documentation said, through a number of techniques listed below:

• 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]