http://blog.forwardbias.in/2011/08/on-webkit-and-webkit2.html
August 9, 2011
On WebKit and WebKit2
Ever heard of WebKit2 and wondering what it means from a Qt perspective? Here’s an attempt to explain QtWebKit and QtWebKit2 in simple terms. I make no attempt to be completely technically correct, it’s meant to be able to explain terminology to the WebKit uninitiated.
In WebKit lingo, “WebCore” is the thing that takes of parsing/layouting/rendering of various css/svg/html documents, providing DOM bindings etc. “JavaScriptCore” implements JavaScript support and is also referred to as SFX (Squirrel fish Extreme). JavaScriptCore can be used as a stand alone JavaScript engine and has no dependencies on WebCore. WebCore uses JavaScriptCore to support JavaScript in web pages. WebCore also contains support for NPAPI plugins (like flash). “WebKit” uses the WebCore to build a platform/toolkit specific API. For example, the Qt “WebKit” port provides QWebElement which exposes the WebCore’s DOM. By definition, WebKit is platform/toolkit/port specific. The Qt port is simply called QtWebKit.
The QtWebKit port is released periodically independent of Qt releases. These ports have the number QtWebKit 2.0, QtWebKit 2.1, QtWebKit 2.2 etc. QtWebKit 2.0 is identical to what was shipped with Qt 4.7.0. QtWebKit 2.1, intended to be mobile friendly, is not part of any shipping Qt release. QtWebKit 2.2, which will be shipped as part of the upcoming Qt 4.8.0, is yet to be released.
Now for WebKit2. The first and most important thing you should know about WebKit2 (even before you know what WebKit2 is) is that WebKit2 is NEITHER AN UPGRADE NOR A NEWER RELEASE of WebKit. It is a parallel port that can happily co-exist with “WebKit”. Let me reiterate: Stop trying to think of WebKit2 as WebKit version 2 
Think of it as a completely different API from existing WebKit.
WebKit is the traditional in-process renderer. If you create 100 web pages, they all reside in one process. If one page causes a crash, it brings everything down. WebKit2 provides a system and an API to make it possible to render a page in a separate process. The process management is taken care of by WebKit2. The actual rendering of the page happens using WebCore. WebKit2, therefore, spawns out processes, renders pages in these processes and makes the end result available to the application. It provides mechanisms deliver events from the application to the rendering process. The Qt port of WebKit2 is simply called QtWebKit2. QtWebKit2 is what is used in the N9 browser.
White-space has never been more important. QtWebKit 2.x is a completely different beast from QtWebKit2. QtWebKit 2.x is plain old QtWebKit releases. QtWebKit2 is Qt’s port of WebKit2. This unfortunate naming is a result of Apple announcing WebKit2 shortly after the Qt guys deciding to call their releases QtWebKit 2.x.
WebKit2 and Chromium are similar in their goal. Chromium does not use WebKit2 and probably never will. The Chromium code was intended for the chromium browser specifically. The WebKit2 code was designed upfront to be an API. This difference in motivation resulted in different implementations. See this page for more details.
Because of the multi-process nature of QtWebKit2, many APIs that existed in QtWebKit simply don’t exist anymore. WebKit2 design lends itself to an asynchronous API compared to WebKit where most API was synchronous. For example, DOM introspection of web pages using QWebElement is not possible since the web page’s DOM resides in another process.
QtWebKit2 has a hard dependency on Qt5 and is very much a moving target like Qt5. QtWebKit will probably not work well with Qt5, we have to wait and see.
Current status: Nokia’s Qt WebKit team has decided to focus on QtWebKit2. They have decided to pass on maintainership of QtWebKit to someone else. At the time of writing, there is no publicly announced appointed maintainer to QtWebKit.
Update: Mentioned about QtWebKit 2.x releases based on Jocelyn’s comment.
To help possibly confused minds, QtWebKit2 can refer to two different things:
- QtWebKit2.x, the independently released QtWebKit.
http://labs.qt.nokia.com/2010/03/03/qtwebkit-releases
- The still officially unreleased Qt port of WebKit2.
Apple announced their WebKit2 project slightly later than QtWebKit’s announcement that it’s release cycle would be detached from Qt. The name was kept.
I propose we name the WebKit2 port of QtWebKit be
called QtWebKit 3.x.
Then we’ll be one step ahead of other ports for those who don’t understand version numbering.
@Thiago: How about call QtWebKit2 based on what it is? Like “QtWebKit MP”. MP for multi-process.
Not to fan the flames, but it’s a funny situation – when QtWebKit finally got a simple DOM API around Qt 4.2 or 4.3 or so, the talk from the WebKit camp was “that’s it, now there’s no more reason to keep KHTML around”. Now that DOM API is effectively unmaintained – unlike KHTML.
“WebKit2 design lends itself to an asynchronous API compared to WebKit where most API was synchronous.”
Is there no way of making it appear synchronous using e.g. threads and QWaitCondition or similar?
As far as I understood QWebKit1 will be continued to be maintained. Security-fixes, etc. will be applied and it’s available in Qt 5. See http://labs.qt.nokia.com/2011/07/07/qwebview-and-friends-are-looking-for-a-new-maintainer/#comment-22873
I don’t understand why you don’t just use WebKit2-Qt.
@Anon (comment #5)
You could do that but then you are basically throwing away the advantages an async API brings. Also you would need to add logic to prevent that your app hangs forever if the other process dies. At the end you would probably earn an app that feels more inactive cause your UI freezes while waiting for the other process.
@Markus (comment #6)
Cause there is some functionality like QWebElement missing atm. Also the API is asynchronous and not synchronous like with QWebKit1 and therefore different. A different API means porting and that’s additional work that may not needed if QWebKit1 already does the job fine in your current code.
I find it great news that QWebKit1 is still in Qt5 while QWebKit2 will be added. The first allows easy porting from Qt4 to Qt5 and the second gives you the WebKit2-advantages. Nice move
Seems to get even worse for KDE webbrowsing, good webkit integration getting more unlikely. Won’t there be any way to run (native) code in the separate webpage process?
Sebsauer: Qt 5 will not have QtWebKit1. It will probably have version 2.2, which is the same as the one in Qt 4.8. QtWebKit 2.2 contains the WebKit1 code internally.
@Thiago
I see. Then s/QWebKit2/QWebKit3/g and s/QWebKit1/QWebKit2/g
@The User (comment #9)
QWebKit2 is there and will be there. KWebKit works fine with it. For QWebKit3 using the WebKit2-engine we already have asynchronous kio/kparts. Probably some work needs to be done to integrate KWallet with QWebKit3? Not sure there. In any case QWebKit2+KWebKit continues to work
@sebsauer
“For QWebKit3 using the WebKit2-engine we already have asynchronous kio/kparts.”
Yes, but processes handled by QWebKit3 may not fit into the kparts-model. I am not familiar with QWebKit3, but integration may be very hard, especially when it is not possible to execute code in the process.
Isn’t QTWebKit2 open source? any GIT repo?
@mike7b4: git://gitorious.org/+qtwebkit-webkit2-dev/webkit/qtwebkit-webkit2-dev.git