Lars Knoll

Introducing the Qt WebEngine

Published Thursday September 12th, 2013
46 Comments on Introducing the Qt WebEngine
Posted in Qt, WebKit

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

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Qt, WebKit


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

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?

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:

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.

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.

Arthur says:

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

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.

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

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.

Get started today with Qt Download now