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]
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]
Comments
It'll be interesting to see how Apple does at next year's Pwn2Own contest with WebKit2.
Finally! This is great news for the safari users out there. Though, I do use Chrome on mac, and I am loving it. The more development for Webkit, the better for everyone (except Microsoft!).
I use Chrome more and more on Windows 7 as IE8, surprisingly, cannot handle rendering properly an ever growing number of websites. The site www.space.com blows in IE8 as an example.
Safari works fine on the Mac though. I do occasionally use Chrome when a site does not support Safari or Safari cannot rendor it properly. Can't stand Firefox though.
I use Chrome more and more on Windows 7 as IE8, surprisingly, cannot handle rendering properly an ever growing number of websites. .... Can't stand Firefox though.
It seems like Chrome on the Mac is the new Firefox (the "anti-Safari" web browser of choice), and that Firefox is on the way out unless it can change.
The sad part is that the things that Mozilla needs to change most (WebKit and support for codecs besides Ogg Theora), aren't going to happen any time soon. They will have to lose a lot more market share before they realise the stupidity of those moves.
I think it's great that Apple is makings split process WebKit2 open source to everyone even direct competitors like Google Chrome. Especially in light of the impression that Apple is a closed, protective company with the iPhone ecosystem and their patent claims. It's clear that Apple is focus on one, obviously making money, but two actually moving technology forward which sometimes requires keeping things close to the chest and other times requires giving it away for free for the benefit of all.
It'll be interesting to see how Apple does at next year's Pwn2Own contest with WebKit2.
I don't think it will make a difference. The problem with WebKit is that it's open source so it's letting anyone in to check to see if the doors and windows are secure. These hackers are just going to find holes and sit on them for a year hoping they aren't plugged.
I don't think people realize exactly how much open source code Apple supports...
I use Chrome more and more on Windows 7 as IE8, surprisingly, cannot handle rendering properly an ever growing number of websites. The site www.space.com blows in IE8 as an example.
Safari works fine on the Mac though. I do occasionally use Chrome when a site does not support Safari or Safari cannot rendor it properly. Can't stand Firefox though.
Do you use Chrome browser or Chrome Frame plugin for IE8? I much prefer the later as I'm a fan of browsers that interact with the system. It feels more natural and elegant so that was the ideal option for me, I just wish they made it easier to configure the Registry to make it on all the time by default.
I think it's great that Apple is makings split process WebKit2 open source to everyone even direct competitors like Google Chrome. Especially in light of the impression that Apple is a closed, protective company with the iPhone ecosystem and their patent claims. It's clear that Apple is focus on one, obviously making money, but two actually moving technology forward which sometimes requires keeping things close to the chest and other times requires giving it away for free for the benefit of all.
It'll be interesting to see how Apple does at next year's Pwn2Own contest with WebKit2.
Where does it say anything about Apple developing this? Webkit is the open source browser code that Apple uses to develop Safari but it was not created or owned by Apple. A lot of if not most development on Webkit is still done by the open source community. If Apple did develop this and add donate it to the Webkit development community I really commend them but I don't think that was the case.
Where does it say anything about Apple developing this? Webkit is the open source browser code that Apple uses to develop Safari but it was not created or owned by Apple. A lot of if not most development on Webkit is still done by the open source community. If Apple did develop this and add donate it to the Webkit development community I really commend them but I don't think that was the case.
It's an Apple derived project fork to better serve their needs. They were the greatest contributors both in manpower and financially. Any reason to believe they still aren't considering how they use it so extensively? Making this available to all isn't just some kumbaya hippie notion, it has allowed WebKit take hold as a viable engine for the internet, and it looks like it worked.
Where does it say anything about Apple developing this? Webkit is the open source browser code that Apple uses to develop Safari but it was not created or owned by Apple. A lot of if not most development on Webkit is still done by the open source community. If Apple did develop this and add donate it to the Webkit development community I really commend them but I don't think that was the case.
Apple OWNS WebKit. They bought out the KHTML project years ago when they started developing Safari and open sourced it as WebKit while still adding to the KHTML project so much of the work being done on WebKit is also available to KDE's Konqueror users as well.
It's an Apple derived project fork to better serve their needs. They were the greatest contributors both in manpower and financially. Any reason to believe they still aren't considering how they use it so extensively? Making this available to all isn't just some kumbaya hippie notion, it has allowed WebKit take hold as a viable engine for the internet, and it looks like it worked.
Good to know.
Where does it say anything about Apple developing this? Webkit is the open source browser code that Apple uses to develop Safari but it was not created or owned by Apple. A lot of if not most development on Webkit is still done by the open source community. If Apple did develop this and add donate it to the Webkit development community I really commend them but I don't think that was the case.
WebKit was created by Apple in 2002 as a fork of KHTML. WebKit was exclusively developed by Apple until 2005 when it went open source. Previously only WebCore and JavaScriptCore were open source. I don't have any exact numbers, but I'm pretty sure the majority of people (or at least man-hours) working on WebKit are Apple employees — around 10 or 15.
Also, in this case, it was developed by Apple contributors
This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework "WebKit2".
You can find the posting here from Apple employees Anders Carlsson and Sam Weinig.
Update: lowededwookie, they didn't buy out KHTML. Also, since it's open source, I'm not sure you can say they "own" the project. They're responsible for a particular branch, but anyone can go off and create their own branch, within the term of the license.
Update: lowededwookie, they didn't buy out KHTML. Also, since it's open source, I'm not sure you can say they "own" the project. They're responsible for a particular branch, but anyone can go off and create their own branch, within the term of the license.
Well they took over the management of it in order to keep the project alive although I guess that doesn't matter now that they have WebKit.
The also own CUPS in the same sense as that's the main printing engine for Mac OS X.
Well they took over the management of it in order to keep the project alive although I guess that doesn't matter now that they have WebKit.
Do you have any sources for this? I'm admittedly more familiar with the WebKit side, but I can't see any reason why Apple would want to manage a KDE project. It's not terribly important by general impression of the chronology was that Apple forked the project, made some changes, gave them back in large commits, the relationship was shaky, Apple went open source and some KDE developers joined WebKit as committers and finally there was some discussion about moving away from KHTML in KDE to WebKit. But that was a few years ago. It looks like progress is slow.
Where does it say anything about Apple developing this? Webkit is the open source browser code that Apple uses to develop Safari but it was not created or owned by Apple. A lot of if not most development on Webkit is still done by the open source community. If Apple did develop this and add donate it to the Webkit development community I really commend them but I don't think that was the case.
https://lists.webkit.org/pipermail/w...il/012235.html
This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework "WebKit2".
As Synotic pointed out, based on the reveal announcement WebKit2 was developed by Apple and now open sourced. And the WebKit development community exists because Apple open sourced the original WebKit. Before I think they were just trying to merge changes back to KHTML, which didn't work so well and lead to frustrations, so Apple decided to just release the whole thing.
EDIT:
https://wiki.mozilla.org/JaegerMonkey
In fact, it seems even Firefox appears to be adopting Apple's open source work since they are adding parts of the Nitro/SquirrelFish Javascript engine to create JaegerMonkey for Firefox. So the big 3 IE alternatives, Firefox, Safari, and Chrome are coming ever closer together in code share, which I guess is kind of the point in offering open source code.
I don't think it will make a difference. The problem with WebKit is that it's open source so it's letting anyone in to check to see if the doors and windows are secure. These hackers are just going to find holes and sit on them for a year hoping they aren't plugged.
I don't think people realize exactly how much open source code Apple supports...
Do you use Chrome browser or Chrome Frame plugin for IE8? I much prefer the later as I'm a fan of browsers that interact with the system. It feels more natural and elegant so that was the ideal option for me, I just wish they made it easier to configure the Registry to make it on all the time by default.
Nothing you said about openness made an ounce of sense.
Do you have any sources for this? I'm admittedly more familiar with the WebKit side, but I can't see any reason why Apple would want to manage a KDE project. It's not terribly important by general impression of the chronology was that Apple forked the project, made some changes, gave them back in large commits, the relationship was shaky, Apple went open source and some KDE developers joined WebKit as committers and finally there was some discussion about moving away from KHTML in KDE to WebKit. But that was a few years ago. It looks like progress is slow.
Apple isn't.
KHTML Devs are merging WebKit-kde [their port] that is non-KPart back into KDE to be used for Konqueror and more stuff.
I am amazed that this situation has been allowed to go on so long. Countless times I have had a tab busy trying to FIND stuff to download and been unable to flip to another tab or scroll it in anything like a rational way.
So looking forward to Webkit entering the 1980's in this regard. Maybe this is what comes from using architects who have only known desktops.