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