Qt WebEngine Technology Preview Available

Published Thursday January 23rd, 2014 | by

We are happy to announce the first Technology Preview of Qt WebEngine. In September 2013, we announced Qt WebEngine as our new Chromium-based web engine to replace Qt WebKit and offer the best possible Web technology for Qt in the future.

In this first Technology Preview, the R&D team focused on properly integrating with Qt and Qt Quick. This paves the way for optimal performance and a competitive and feature-rich web browsing experience.

In the following video you can see how well Qt WebEngine integrates into Qt Quick.

At the moment, we have both Linux and Mac OS X supported and we are working on bringing Qt WebEngine to other platforms, such as Windows and Qt Enterprise Embedded Android/Linux. There is currently a preliminary API for Qt Quick as well as for Widgets. The implementation for Qt Quick integrates directly with the Qt Scene Graph and therefore allows better performance for accelerated web content. The Widgets API is focusing on ease of porting from QtWebKit.

Please keep in mind that as we are currently in a Technology Preview stage neither the Qt Quick, nor the Widgets API for Qt WebEngine is considered stable. At this time, source and binary compatibility are not guaranteed.

How to Get the Code

A source tarball can be downloaded from the Qt Enterprise Customer Portal, as well as from qt-project.org.

If you choose to use git for cloning our Qt WebEngine repository, please make sure to checkout the tag v0.1.0-tp1 and follow the instructions on our Gitorious repository page. https://qt.gitorious.org/qt-labs/qtwebengine

How to Build

Qt WebEngine currently requires Qt 5.2 or later. All you need to do is execute qmake and make install in the Qt WebEngine source directory. Internally the build process uses gyp and ninja, but there is no need to worry, this is all nicely hidden from you.

qmake && make install

Note that the make install step is necessary to put all the resource files that are needed by Chromium into the right place. Otherwise I10n and Inspector resources will not be found.

The following examples are included

The Qt WebEngine repository includes examples for both Qt Quick and for Widgets in the examples/ subdirectory.

  • QuickNanoBrowser is a very simple example of a multi-tab browser using Qt Quick. It can be used to showcase the actual performance for WebGL that can be achieved by integrating with the Qt Scene Graph.
    To be able to share textures with the Qt Scene Graph efficiently we have to use shared contexts. For details about this take a look at the file quicknanobrowser/main.cpp.
    In case you have multiple GPUs installed in your system, you might also need to pass –supports-dual-gpus on the command line.

  • Browser is the original QtWebKitWidgets based Qt demo browser ported to Qt WebEngine. Several features are still missing, but it is already a good example for porting an application from QtWebKit to Qt WebEngine.

  • FancyBrowser is another example ported from QtWebKitWidgets. It shows the interaction with web content using jQuery and the asynchronous runJavaScript method.


Qt WebEngine currently uses the Chromium networking layer. Therefore, we do not have an integration with QNetworkAccessManager. Also, we are currently not supporting the Adobe Flash plugin.
While the quality of displayed web content is already at a very good level, the APIs are not fully complete. In particular, the Widgets API is still lacking several features, but we are working on resolving this issue.

What’s Next

We are planning to have an Alpha and a Beta release of Qt WebEngine within the first half of 2014. In the Alpha release, we intend to add support for Windows. We are also working actively to provide embedded Linux and embedded Android support for our Qt Enterprise Embedded offering. In addition, we will of course keep working hard on the Qt Quick and the Widgets API to support further use cases.

How to Provide Feedback

If you find bugs or have specific feature requests, please file a bug-report on https://bugreports.qt-project.org for the project Qt and the component WebEngine.

If you are planning to use Qt WebEngine and are interested in setting feature priorities, but are not able to contribute directly to the development, you can help us direct resources towards Qt WebEngine by becoming Qt Enterprise licensee or establishing another commercial agreement with Digia. You can also provide feedback by sending us an email: qt.webengine@digia.com

Where to Get More Information

Our rather minimal wiki page can be found here: http://qt-project.org/wiki/QtWebEngine
If you are planning on contributing to the development of Qt WebEngine, please sign up to our mailing list at: http://lists.qt-project.org/mailman/listinfo/qtwebengine or find us on our freenode channel #qtwebengine.

Did you like this? Share it:
Bookmark and Share

Posted in Qt, Qt Quick, Qt WebEngine, Uncategorized

39 comments to Qt WebEngine Technology Preview Available

TheBootroo says:

I can’t get it to compile, here is the output :


I’m on Ubuntu 13.04, 32 bit, GCC 4.7.3, Qt 5.2…

Jocelyn Turcotte says:

There seems to be an issue with grit and paths containing non ascii characters: http://code.google.com/p/gyp/issues/detail?id=265

Does ~ point to a path containing UTF-8 characters?
Could you try building it from a path containing only ascii characters?

Arunprasad Rajkumar says:

Nice work guys :)

Pretty cool stuff!
I love the mixing of web content with shader effects..

zac says:

Pretty cool. But you mentioned the roadmap that there will be porting to Qt Enterprise Embedded Android/Linux, is that means there will be no support of webengine in android and linux for the opensource version?

Tuukka Turunen says:

@zac: Linux and Mac are supported in this technology preview for both open-source and Qt Enterprise.

Scott Brady says:

Ahh you say supported in the technology preview, but what about the final version. Will it be available it still be available for opensource versions.

User says:


Charles says:

Makes me wonder if Jolla will dump their Mozilla-based browser which is quite awful, and replace with a properly integrated QtWebEngine-based browser. I do hope so.

Hillary H. says:

And iOS?

… and something that passes through the Apple’s App Store?

Will Chrome for iOS be …?

Pierre says:

As you rightfully pointed out, due to the app store’s policy, that would not really be an option on iOS. Moreover, it is not clear how well-advised it would be to ship what can be a fairly massive library on mobile platforms simply for the sake of using a webview, which all the mobile platforms Qt is targeting already provide in one form or another. This is why we are not looking into bringing QtWebEngine to mobile platforms at this point. We are aware of the need for a simpler WebView API, and it is something that is currently being investigated for the mobile ports (that same API could probably be made available on other platforms on top of QtWebEngine, but that would be more of an implementation detail in that case).

J says:

If we had a common API for -any- web rendering technology that went across platforms, even if it targeted a different technology on every platform, then I’d buy it.

I know that all of these platforms have APIs for some sort of WebView, but as Qt using developers, we must learn to support iOS (and learn Objective C), Android (and learn Java), and Windows Phone (and maybe Cx) just to put a WebView in an app where the rest of the code is C++, and already portable to Windows Desktop, Linux, and Mac through Qt’s excellent abstraction.

Hillary H. says:

The comment “ship what can be a fairly massive library on mobile platforms ” … *entirely*misses* a key consideration.

WebKit *already* exists in iOS … Qt just needs to work with the native WebKit resource … no “fairly massive” library.

IMHO, Qt should leverage which ever web engine is native with an sensible cross platform API.

Tuukka Turunen says:

@J & Hillary H: Pierre wrote in his comment: “We are aware of the need for a simpler WebView API, and it is something that is currently being investigated for the mobile ports (that same API could probably be made available on other platforms on top of QtWebEngine, but that would be more of an implementation detail in that case).” For the moment web on iOS and Android Qt apps needs to be used through the native APIs. We’ll provide more examples how this is done – it is not difficult. And in the future the most likely is a cross-platform way to do it, as Pierre wrote.

Hillary H. says:

@Tuukka Regarding, “used through the native APIs … it is not difficult”, this is exactly the point! For our projects which use the Chromium-based web engine, this new Qt WebEngine has *zero*value*added*.

@Tuukka & Pierre “need for a simpler WebView API”, how about simply putting priority on a excellent core cross-platform abstraction which includes mobile … sooner rather than later?

Zeno Albisser says:

@–marc: It is not about picking sides, but about picking what allows us to provide better quality and support for different platforms. Chromium by itself is cross platform. So Qt WebEngine is a step into the direction of better cross platform support.

A cross platform WebView which is not based on QtWebEngine, but just abstracts native web rendering engine must be more simple. This is simply because abstractions can only make use of the “lowest common denominator”.

J says:

@Tuukka: Thank you in advance; examples of mobile browser integration (with network access interception, please) would be greatly appreciated.

MarcinUI says:

Can anyone tell me if there is already support for WebRTC

Simon says:

WebRTC is working but not enabled by default – we don’t have the UI in place to ask for the camera/microphone access. If you look into gerrit you can see a work-in-progress patch for that. It is one of the things we’d like to enable for the next release.

Emanuele says:

Hi Simon, I’ve successfully compiled QtWebEngine on Linux from the source code. Now I’d like to enable WebRTC even if its support isn’t completed yet. What should I do to enable it? There are some instructions anywhere?

Jason says:

This is cool, but I want it to work the other way. I want QML to work in a web browser, with no plugins.

J says:

Yes, the Qt 5 NaCl port really needs some love.

J says:

This tech preview is really great! I’ve thrown a ton of pages and WebGL commands at it, and it handles most of them well, and all of them much faster than QtWebKit does.

The post mentions that there’s no QNetworkAccessManager integration, yet. Is that coming in the alpha or beta release? If not, is there any network access interception mechanism available?

Pierre says:

QNetworkAccessManager would probably not be the right level of integration, except for some sort of a “compatibility mode” maybe, because we want to leverage Chromium’s network stack as much as possible. There are a few things that could be done to expose some control over the network access, one candidate in particular would be to expose custom protocol handling (the way we currently handle qrc), could that be good enough?

J says:

@Pierre: Perhaps scheme handlers may be enough for new apps, but I believe that CEF has a “bool shouldThisBeHandledByACustomHandler(url)” callback function (I can’t remember its real name.) that an app would register, so it could quickly tell the network stack to either handle the URL or (still an action by the network stack) call another callback registered to handle all URLs for which the above function would return true. I believe that a such a mechanism would be preferable to only checking the scheme.

J says:

@Pierre: Let me clarify what I had in mind:

A callback that takes an URL and returns a bool would be called for each request. If the callback returns false, use Chromium’s network stack, and if it returns true, use QNetworkAccessManager. If a callback was not set, then always use Chromium’s network stack.

QNetworkAccessManager can still be used as the abstraction point for QtWebEngine, but it would be the alternate way to get to the network, not the normal way: The data structures needed for “createRequest” don’t need to be populated if the callback says to use Chromium’s network stack.

In my own case, there’s state in my derived QNetworkAccessManager that would need to be shared to any other access mechanism, so I believe that QNetworkAccessManager support is very important considering that QtQuick uses it as well, and if one writes a custom QNetworkAccessManager for QtQuick, then there shouldn’t be too much effort required to get it to work with QtWebEngine or…

J says:

I’ve had a crash a few times, and I found a public site that reproduces it very well. Is there a bug tracker URL?

Just so you know:
1) Go to http://simpl.info/rtcdatachannel
2) Click on “View source on github” at the bottom of the page.

It looks like WebContentsAdapter::activeUrl() is at the top of the stack when it crashes. This same crash has happened on multiple sites that do -not- seem to be related by features that they use. I believe that clicking on the “view this video on YouTube” button caused it as well (from this blog entry).

Tuukka Turunen says:

@J: If you find bugs, please file a bug-report on https://bugreports.qt-project.org for the project Qt and the component WebEngine.

--marc says:

I have three overriding concerns with the current Qt WebEngine direction:

Concern 1. Cross-Platform Neutrality. Is Qt WebEngine loosing its way from being a premier cross-platform platform leader to become some lesser follower by taking sides between the Apple vs. Google battle?

Concern 2. Mobile Platform Availability. So, Qt WebEngine is being delay as something “simpler”, later, and … ?

Concern 3. Abstraction Quality. Apple ended up with many major changes to the desktop APIs, after gaining experience in mobile devices. The notion that mobile is “simpler” is naive. Addressing Android/iOS mobile sooner & concurrently with desktops, can provide for a better Qt WebView API design for all platforms.

Flushing out a cross-platform Qt WebView Core across all major mobile & desktop platforms, IHMO, seem like the place to start … then, add Qt WebView Extension(s) as needed.

Ian Monroe says:

But the point is you can’t ship your web toolkit on iOS. Qt WebView on iOS is never ever going to happen. And while you can ship 50 megs of web browser with your Android app, you probably don’t want to.

It appears that WebEngine will have an API that is less coupled with the underlying engine.

Note the talk is about Chromium, not Blink – this is not the deep integration that WebView has with WebKit. It’s happening at a higher layer.

Stephen Chu says:

Got this error when building on Mac:

Undefined symbols for architecture x86_64:
"ui::GetFlingData(NSEvent* const&, float*, float*, float*, float*, bool*)", referenced from:
ui::ScrollEvent::ScrollEvent(NSEvent* const&) in libui.a(ui.event.o)
"ui::GetScrollOffsets(NSEvent* const&, float*, float*, float*, float*, int*)", referenced from:
ui::ScrollEvent::ScrollEvent(NSEvent* const&) in libui.a(ui.event.o)
"ui::GetChangedMouseButtonFlagsFromNative(NSEvent* const&)", referenced from:
ui::MouseEvent::MouseEvent(NSEvent* const&) in libui.a(ui.event.o)
ld: symbol(s) not found for architecture x86_64

harsh jahagirdar says:

From all the information available on the web related to this Chromium based Qt WebEngine, it is not clear to how this works on embedded platforms (proprietary) to which Qt is already ported. To clarify, Qt Webkit was automatically available on a platform if Qt was available on that platform (through QPA porting) as QtWebkit was dependent only on Qt and hence QPA porting and no other dependency was there between Webkit and the native platform (ignore the MediaPlayer part). Where as for this Chromium based Qt WebEngine, I am assuming that Chromium needs to be independently ported to the native platform for the QtWebEngine to work. Or will Qt provide some adaptation layer that takes care of mapping Chromium’s platform dependency to QPA, thus relieving the task of implemnting Chromium’s platform adaptation to the native platform. Can some one provide more clarity on this?

veveve says:

I’m sorry for writing here, but I don’t know, where I can submit information Qt WebKit bug.

Qt WebKit has memory leaks, that makes impossible to use it for loading many pages, see discussion here:


Will anything be changed in QtWebEngine?

Michael Brüning says:

Hi veveve,

to report bugs in QtWebKit, please go to https://bugreports.qt-project.org and look for the project Qt and the component WebKit. You will also find a bugtracker for the WebEngine component there.

This specific problem is being worked on and there is a fix being merged at the time of this writing: https://bugreports.qt-project.org/browse/QTBUG-34494 .

João Barbosa says:

Are touch events handled in the webview?

prabindh says:

Why does the build require gtk+ ? This rules out quick checks in many embedded distros.

prabindh says:

Completed a round of investigation on the build, and it appears that the below are required on any Linux build. gtk, nss, gconf, x11, xfixes, pangocairo/ pangoft2. Would there be a version that only relies on Qt and not on other packages (like how qtwebkit integrated everything) ?

Zeno Albisser says:

@prabindh: I am not sure it is the complete list of dependencies, but it is for sure the most “important” ones. The dependency to x11 / xfixes will go away when we integrate with Qt Enterprise Embedded. Which will then be using EGLFS. However for desktop linux this will obviously remain a dependency. The dependency to GTK is IIRC only a build time dependency, and it is supposed to go away soon as well. We are actually working on that.
However, we might still have some dependencies on top of “just Qt”, because we are trying to keep our changes to Chromium to a minimum, in order to benefit from the high stability that is provided by the Chromium project.

prabindh says:

@zeno This list has the ones that I do not have in my current Yocto build and had to scavenge them one by one from system.gyp/ui.gyp before I stopped. But thx for confirming that we will get to my favorite eglfs. Will track the changes for this.

Commenting closed.