#qtwebkit

A few days ago I was doing a port of a QtQuick 1 embedded software to QtQuick 2. In this software there's a browser which has some fairly standard functionality such as: SSL certificates updates, security exceptions for invalid SSL certificates, custom behaviour for unsupported MIME types.

All of this was fairly straightforward in QtQuick 1 because you could create a custom network access manager for your QML engine (through a custom QNetworkAccessManagerFactory) and WebKit would simply use that. However, this is no more the case for WebKit2.

Let's quickly review the architecture of WebKit2:

UIProcess: the process responsible of communicating with the user

WebProcess: the rendering process

The two communicate via a channel with a set of standard messages.

When you want to port WebKit to your platform, you need to implement two things: the public API, which is what your users will see, and the process API, which is needed by the WebProcess (for example, network communication).

This is a fairly standard pattern when creating large and modular software. So, how is Qt connected to WebKit?

At the public API level it exposes the QML WebView element and other C++ classes (QWebPage, QWebFrame...)

At the WebProcess API level, it uses standard Qt classes to implement the low level WebKit API; in particular, network requests are handled by an instance of QNetworkAccessManager.

Now we see that the main process' NetworkAccessManager is not used to download web pages, since such communication is done in another process.

So, how to implement SSL root CA certificates update? Just update them at the system level, under /usr/lib/ssl/certs/.