Introducing the Qt WebEngine

Published Thursday September 12th, 2013 | by

A lot has happened with Web technologies in general since we introduced the first version of Qt WebKit in 2007. From having a couple of percent market share, the WebKit open source project nowadays has became the most widely used browser engine in the world. While the Qt port of WebKit was pretty much the first non-Apple port of WebKit, many other projects and companies joined the project over the years to follow.

The Chromium project took an especially big role in the project and became over time the biggest contributor to WebKit (followed by Apple and with Qt on the third place). The cooperation between different companies on one open source project was, however, never without difficulties, and this spring Google decided to leave the WebKit project in favor of their own fork of WebKit, Blink.

Since then, Blink, which really is a very integrated part of Chromium, and WebKit have been going separate ways, and the two code bases have been rapidly diverging. Because of this, the Digia Qt R&D WebKit team decided to have a closer look at both Chromium and WebKit to decide how we could offer the best possible Web engine for Qt in the future.

After spending some time researching and looking at both alternatives, we have now come to the conclusion, that we will base our future Web engine on Chromium. The Qt WebEngine. There are many reasons that lead to this decision:

  • Chromium has a cross-platform focus, with the browser being available on all major desktop platforms and Android. The same is no longer true of WebKit, and we would have had to support all the OS’es on our own in that project.
  • There are many things that are available out-of-the box from Chromium, which would require a lot of work for us to support ourselves in WebKit. One example, is the whole platform/OS adaptation that we can simply re-use. Multimedia and new HTML5 features such as WebRTC are working out-of the-box and don’t require any Qt-specific code.
  • As using Chromium simplifies handling the OS integration, this allows us to spend additional time to focus on the upper layers to provide a great and easy-to-use API and a seamless integration into Qt as possible.
  • We are seeing that Chromium is being developed with very strict control on quality. This simplifies our testing efforts and will allow us to provide a more stable and higher quality Web engine.
  • Chromium will allow us to do a better and more performant integration with both widgets and the Qt Quick scene graph than we would be able to do with WebKit

Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available. Basing our next-generation Web engine on Chromium is a strategic and long-term decision. We strongly believe that the above facts will lead to a much better Web engine for Qt than what we can offer with Qt WebKit right now. We also believe that the combination of the best-in-class browser engine with Qt as a native framework gives an incredibly strong offering especially for the creation of embedded devices that require a Web browser in addition to best-in-class UI performance.

One of the fundamentals of Chromium is that all rendering of Web content happens in a different process for security and stability reasons. This does, however, make it impossible to provide certain aspects of our current Qt WebKit API with Chromium. One notable part is probably the QWebElement API. We will also have to change how QObject embedding is being done, since all communication between the QObject and the web page will have to happen asynchronously.

What does all of this mean for users of Qt WebKit?
First of all, there’s nothing to be afraid of. For many use cases, where Web content is being embedded into applications, Qt WebKit works fine right now, and will continue to do so in the years to come. After the release of Qt 5.2, we will focus most of our new development efforts on the new Qt Web Engine. So, if you want to have all the lastest and greatest HTML5 features available for your application or device, you should consider moving over to Qt WebEngine once we have a release that covers the API features you require.

We will do our best to make moving over from Qt WebKit to the new Qt WebEngine as easy and seamless as possible. For the Qt Quick WebView element, we can most likely provide a close to 100% compatible API. For people using the basic QWebView API, we also have good news. Most of that API is available in an almost source-compatible fashion in the new Qt WebEngine. If you use the QObject bridge or the QWebElement API, we recommend you wait a bit longer with moving, as a replacement API for those will most likely not be part of the first version of Qt WebEngine.

While we no longer will do any feature development in Qt WebKit, the existing version will continue to be available. Digia will continue to support Qt WebKit for Qt Enterprise commercial license holders as defined in the license agreement, and can also offer extended lifetime support.

Work is now ongoing to provide you with a Technology Preview of the new Qt WebEngine as fast as possible. Our goal is to have that available together with the Qt 5.2 release this autumn. The first fully supported release will then, most likely, come as part of Qt 5.3 next spring. For the first version, we are planning to support the new Qt WebEngine module on Windows, Mac OS X, Linux and embedded Linux.

For more information on the Qt WebEngine have a look at the Qt Project wiki. There you can also find more detailed information about how to build the Web engine yourself, how to port existing code and what our future plans for the module are.

While this is a rather large change for Qt, I strongly believe this will give us a much better and more competitive Web platform in the years to come.

The best way to find out what is going on with Qt WebEngine and our future direction is to join us at Qt Developer Days where our lead developers on the project will talk about the latest developments. Make sure to register to Qt Developer Days at

Did you like this? Share it:
Bookmark and Share

Posted in Qt, WebKit

46 comments to Introducing the Qt WebEngine

Alastair says:

“If you use the QObject bridge or the QWebElement API, we recommend you wait a bit longer with moving, as a replacement API for those will most likely not be part of the first version of Qt WebEngine.”

Hi! Does this imply that there *will* be a replacement for QWebElement, and what will such an API look like, given that the old API is “impossible”?

Cheers! :)

Very nice work, guys :-) Looking forward to give it a try.

teho says:

Will this mean that Chromium extensions, PPAPI Flash Player and NaCL will also be available for Qt WebEngine?


Zeno Albisser says:

@Alastair: We are planning to develop a solution to interact with the web content. How exactly this solution is going to look like API wise, we do not know yet.
@teho: Our first priority is to get the basic use cases right on our main platforms. While I would not rule out the possibility of supporting such features, they are currently not being worked on.

Alastair says:

“@Alastair: We are planning to develop a solution to interact with the web content. How exactly this solution is going to look like API wise, we do not know yet.”

Thanks, that’s re-assuring :)

Cosmo says:

Great! Excellent news :-)

I’m not familiar with all the names of the components.
In short, when will we be able to expose and use a C++ QObject from Javascript through addToJavaScriptWindowObject() and will be able to evaluateJavaScript() from C++?

gremwell says:

This is all I need too, expose QObjects to JS so that the JS can call through to C++, and the ability to evaluateJavascript so that I can call from the C++ into my JS.

I don’t even use the nice signal/slots integration. As far as I can see, you can work around pretty much everything else if you have a the bridge to be able to call in and out.

Ian Monroe says:

Thanks for the update.

I use QWebElement to append, prepend and just to pass some DOM object that I want to give some JavaScript code a chance to look at and modify, sort of a view/model separation. So I think if there was a way to insert HTML before or after a given id that would be enough… could then use some of the new JavaScript APIs that let you watch the DOM tree being manipulated. Or even better Qt could include some clear JavaScript APIs by default.

Honestly I’d like to switch the whole thing over to QML though. I might just skip WebEngine. ;)

Ryan says:

Why create a new API? Why not use the current API? There shouldn’t be competing APIs for the same functionality! (i.e. don’t do the same as QScriptEngine vs QJSEngine)

Daniel Molkentin says:

Will this have any effect on the existing Qt networking stack or those worlds stay separate?

Simon says:

Those worlds will stay separate at the moment :)

TTGil says:

How does this change impact iOS platform support? Will web content be rendered using native Webkit or Chromium?

ben says:

I don’t think Chromium supports iOS.

Thus I, too, would be interested in hearing what the Qt devs have planned for that platform.

Morten Johan Sørvig says:

So far it looks like using the native UIWebView is the only option on iOS.

raven-worx says:

since Apple restricts the usage of another webengine other than their owns on iOS you wont see chromium there.

Donald says:

I really like working with the Chromium code base; there is so much good code in there (some people might see it as NIH, I just see spans of useful BSD licensed code)

I am juiced for this :) by god does Chromium move quickly

[...] the Digia blog, Lars Knoll announces that Qt has decided to migrate its web rendering engine from WebKit to Chromium. First among the [...]

[...] información – Chromium abandona WebKit para adoptar su fork: Blink Fuente – Qt Blog googletag.cmd.push(function() { googletag.display('div-gpt-ad-1378804021878-2'); }); [...]

devbean says:

Based on Chromium or Blink? IMO Chromium is based on Blink. What is the new Qt WebEngine? What about API? Is it compatible with QtWebKit (QWebElement and so) or a totally new API? Does this mean QtWebKit is dead?

[...] has announced that it is switching from WebKit to Chromium for its QT WebEngine. QT joins Opera in following Google’s lead after forking Blink, the [...]

[...] the company that now controls Qt after buying it from Nokia last year, said in a blog post that its Qt R&D WebKit team had taken a close look at both Blink and WebKit, with [...]

Aaron Stone says:

It’d be amazing if the Chromium work also brought in something like Antialize’s work on QWebPrinter that makes it easy to render out to an image:

[...] has announced that it is switching from WebKit to Chromium for its QT WebEngine. QT joins Opera in following Google’s lead after forking Blink, the [...]

worriedQtCoder says:

As someone who’s job depends on the existence of the QWebElement API, I am a little worried about the vagueness of your comments in relation to its replacement. The ability to use CSS selectors on the DOM is paramount to the project I have been working on for years. Suddenly no longer having that would be rather catastrophic.

Any light you could shed on this topic would be greatly appreciated.

Hronom says:

Its the best thing that i heard from Qt devs at last time. If you provide more deeper integration(more control) in future versions its will be AMAZING.

[...] Más información – Chromium abandona WebKit para adoptar su fork: Blink Fuente – Qt Blog [...]

Pierre says:

@worriedQtCoder: feel free to give more details about your use cases. As Zeno stated above, the plan is to provide that sort of functionality, but whether the API will look the same is a different question.

worriedQtCoder says:

I use it to search the DOM of a given page, and keep QWebElement references to those HTML entries found. This is a process that is repeated until the desired node or nodes are found.

CSS selectors are used to achieve this. Once those nodes are found, they are converted to text, either with the toOuterXml(), toInnerXml(), or toPlainText() member functions(context dependant). Further processing may take place on the text returned at that point.

The ability to store and re-use the found DOM nodes as new starting points for further CSS selector searches is absolutely required.

Simon says:

Perhaps a solution for your use-case involves executing the dom/css inspecting code as Java Script on the web process level and reporting the result back to your c++/qml code. Think of injecting scripts for example

worriedQtCoder says:

That would probably not be feasible, as I need to not only store the text result of the found node, but also the pointer into the DOM(QWebElement object reference) for future use.

gremwell says:

Store the id, document.getElementById() is a hash lookup and very fast. Any operation just calls through to the relevant JS passing in the ID rather than the element itself.

[...] Lars Knoll im Q-Blog von Digia schreibt, steht der freien Klassenbibliothek Qt ein Umbruch bevor. Im Jahr 2007 führte Qt die Klasse [...]

Arthur says:

Nice new news? But what will be with apple WebKit tree?

[...] Gründe für die Entscheidung zur Abkehr von WebKit nennt Qt-Entwickler Lars Knoll im Qt-Blog in erster Linie den Cross-Plattform-Ansatz Googles, Chrome auf allen wichtigen Plattformen [...]

[...] bien, Lars Knoll ha anunciado en el blog de Qt que a partir de la versión 5.2 de este «toolkit» multiplataforma se dejará de desarrollar Qt [...]

[...] Vergleich mit Webkit biete Chromium verschiedene Vorteile, schreibt Lars Knoll im Qt-Blog: Chromium habe anders als Webkit einen Fokus auf Plattformunabhängigkeit und unterstütze neue [...]

[...] beliebte Applikations-Framework Qt wechselt die Browserengine. Wie es mitteilt, wird es seine für Qt WebKit zuständigen Ressourcen künftig für ein neues Projekt namens Qt [...]

What influence will this have on licensing? WebKit was always in so far problematic, that even with a commercial Qt license one was stuck with the LGPL when QtWebKit was necessary. From the chromium wiki the licensing is a bit unclear for me.
> The Google-authored portion of Chromium is released
> under the BSD license, with other parts being
> subject to a variety of different open-source licenses,
> including the MIT License, the LGPL, the Ms-PL and an
> MPL/GPL/LGPL tri-license.
What are non-Google-authored necessary Chromium parts? Will it be possible to get rid of the forced LGPL?

M.S. Babaei says:

You can’t get rid of LGPL restrictions unless chromium maintainers stop using LGPL parts of the code or the original author re-license it with a more permissive license.

[...] Knoll, creador del motor KHTML, director de desarrollo del proyecto Qt en la compañía Digia, introdujo Qt WebEngine, un nuevo componente de motor de navegadores utilizado en aplicaciones Qt. Qt [...]

I am also very excited about it, I’m looking forward to try!

[...] Google forking WebKit to create Blink, Digia has been looking at what fork to follow and has now decided to go with Chromium and Blink. This means the QtWebKit development will be frozen after Qt 5.2 and the new QtWebEngine which will [...]

[...] Qt5 wechselt zu Blink bzw. Chromium als Basis für die WebEngine [...]

Cornelius Hald says:

The FAQ states: “We intend to make QtWebEngine available on all platforms that the upstream Chromium project supports, with the exception of Android. This also means iOS won’t be supported.”

So no Android and no iOS support? What are the plans for those platforms?

J says:

QtWebEngine looks good for desktops.

I have a problem, however. I’d like a widget or (QML element) that displays web content in which one can expose QObjects to Javascript and control its network access with QNetworkAccessManager no mater which platform I’m on.

It seems that for an app that spans Windows, Mac OSX, Linux, Android, iOS, and Blackberry 10, Qt has no way of doing what I described above without resorting to platform specific APIs.

This use (a bare HTML5/C++ hybrid app) seems to be completely overlooked, and yet, it seems that it would be very common. I understand that QML is the way that I should go if I have such an app, but let me explain my motivation: I (like many) have some HTML5 libraries that I -must- use for visualization in an upcoming App that I’m moving from web-only to hybrid, so I really need a cross platform WebView, even if most of my on screen elements are QML.

Chrome has come to many platforms utilizing the native WebView instead of its own where its own was prohibited (iOS, etc.). I don’t know Chromium well enough to know if that abstraction is at the Chromium level or in unreleased code, but I would say that if QWebEngine can’t be portable to the mobile platforms as well as desktops, then there needs to be a “wrapper” widget/QML element that chooses some webview appropriate to the platform that exposes an API that’s common across all platforms, even if that common API is fairly shallow (deeper control APIs could be determined per platform, but there should at least be something known, such as “setUrl()”, “executeJavascript()”, and “setNetworkAccessManager()”).

Is something like what I described above planned?

Alex says:

I don’t see build instructions for Windows in the readme ( Am I missing something, or no trying the new engine on Windows yet?

Commenting closed.