Thursday, August 18, 2016

QtWebKit: I'm back!

Hello world!


Five years have passed since the last entry in this blog, and almost 3 years since infamous "Changes in QtWebKit development" thread at Fortunately, we've made quite different kind of change in QtWebKit development lately, and it is much more exciting.

QtWebKit is back again!

If you were following QtWebKit development after 2013, you know that actually development have never stopped: each release was getting a bunch of bugfixes and even brand new features. However, WebKit engine itself has not been updated since Qt 5.2 release. That's why it didn't support recent changes in Web standards that happened after 2013, including: new JavaScript language standard ES2015 (also known as ES6), as well as improvements in DOM API and CSS.

However, things have changed in 2016, and now we have revived QtWebKit! Core engine code was updated to it's actual state, and as a result we (and you!) can use all improvements made by WebKit community during these 3 years without any changes in code of existing Qt applications!

You may be wondering, why anyone would like to use QtWebKit in 2016, when shiny new QtWebEngine is available? There is a number of reasons:
  • When used in Qt application, QtWebKit has smaller footprint because it shares a lot of code with Qt. For example, it uses the same code paths for drawing and networking that your regular Qt code uses. This is especially important for embedded systems, where both storage space and memory are scarce resources. It's possible to go further and cut away features which are not crucial for your application, using flexible configuration system of WebKit.
  • On Linux QtWebKit uses GStreamer as a default media player backend. This means that application users will be able to use patent encumbered codecs (if this is legal in their areas) without getting you (as application developer or distributor) into legal troubles.
  • Lots of existing open source applications depend on QtWebKit, but without security updates their users are left open to vulnerabilities. The are only two ways to work around this problem: port applications away from QtWebKit (which is often a hard task because QtWebKit allows much deeper integration with application code than alternative solutions), or update QtWebKit itself, which makes these large porting work unnecessary.
  • QtWebKit is more portable than Chromium: it can run on any CPU architecture supported by Qt and on virtually any Unixish OS (as well as Windows and Mac). The only requirement is a C++11 compiler.
  • Non-interactive user agents like PhantomJS or wkhtmltopdf don't gain any benefits from multi-process architecture, so using single-process WebKit 1 API allows them to have less resource footprint and simpler flow of execution.

Q: I've heard that WebKit engine is not relevant anymore, since the crowd is working on Blink these days!

A: This is not true. Despite of the Google departure, WebKit remains on of the leading browser engines, and is progressing at a fast pace. If you don't believe, read on! Also you may want to read release announcements of Safari Technology Preview and WebKitGTK, which higlight other WebKit features under development.

Now let's see what can we do with QtWebkit in 2016!

JavaScript engine improvements and ES2015 status


Most of features are supported now (QtWebKit 5.6 has 10% rating). Note that WebKit is the first web engine providing proper tail calls, which means you can enjoy functional programming without unnecessary stack growth in tail recursion!

WebKit gained new tier of JavaScript JIT compilation, called FTL. First implementation was based on LLVM compiler infrastructure, but now we are shipping B3 compiler which is more lightweight, does not pull in additional dependencies, and also compiles faster. FTL usually gets activated for computationally-intensive JS code, and is especially useful for running native code compiled to ASM.js.

Code produced by JavaScript JIT now uses normal C stack, reducing overall memory usage and fragmentation.

JIT compiler now uses background threads, so compilation does not block execution of other code.

New (and old) CSS properties

Web standards evolve rapidly, and more and more CSS properties find their way into specification. Most of them have already been available for a long time, but used -webkit vendor prefix as they were non-standard extensions at a time of their introduction, and now they (finally!) have formal description which all vendor are obliged to follow (though sometimes standardization process changes behavior of old properties). Standardized properties are available without vendor prefixes, and web page authors start actively using these new spelling.

Unfortunately, sometimes they break compatiblity with old browsers, which implement prefixed properties, with disastrous consequences. Here are screenshots of site that uses unprefixed flexbox properties, defined in CSS3:

QtWebKit 5.6

QtWebKit TP3

CSS Selector JIT

Besides JavaScriptCore, WebKit now features yet another JIT compiler. Its aim is to speed up application of CSS style sheet to elements of page DOM, so called style resolution. Average performance gain is about 2x, however for complex selector and/or pages with lots of DOM nodes gain may be substantially larger.

Selector JIT also makes querySelector() and querySelectorAll() faster, but speed up factor may differ.


This is new CSS property, allowing page author to create "drop cap" effect without much hassle. In order to make this effect work correctly with calligraphic fonts, Qt 5.8 (not yet released) is required.

Other improvements

  • Responsive images support (<picture> element, srcset and sizes attributes)
  • ellipse() method in Canvas API
  • CSS selectors ::read-write and ::read-only
  • HTML <template> element 
  • APNG images

We also support following web features with experimental status and only for GStreamer media player backend:
  • Media Source Extensions
  • WebAudio

The path ahead

Unfortunately, porting Qt-specific code to the new WebKit is not always easy, and we had to disable certain features until all code behind them is ported properly. So far, following prominent features are not yet working:
  • WebGL and CSS 3D transforms
  • Accelerated compositing
  • Private browsing
However, don't be discouraged! Work is in progress and we hope to get these feature available soon. But we are short on manpower so we cannot work on many things in parallel. If you want to get your favorite feature ready sooner rather than later, please join our project. We have a lot of work to do, most items don't require any prior knowledge of WebKit, and some even don't require you to know C++ (yes, there is work for those of you who know only HTML + CSS + basic JavaScript, or only Python). Another way to help us is to report bugs you have found, or help to track down known issues.

You can follow development of QtWebKit at GitHub repository; however if you want to obtain get bleeding edge sources, use another repository - the latter one is much smaller than original, but still contains all files required to build QtWebKit. See our wiki for build instruction and additional information about the project.


Today is 10 years since the first chunk of QtWebKit code have been merged into WebKit repository. See for more details.


Technology Preview 3 is now available: release notes, tarball. Binaries for Windows and macOS will be uploaded a bit later.

Update 2

Technology Preview 5 is available now. It includes binaries for Windows (MSVC, MinGW), macOS, and Linux, that are fully compatible with official Qt 5.8.0 SDK.


  1. What about QWebEngine ? When should it be used ?

    1. When you need support for certain Web platform features which are not yet available in QtWebKit, or experimental Google-only technologies like QUIC protocol, NaCl applications, or PPAPI plugins.

  2. Having trouble getting the QTWebkit to load my flash swf content. I've set the QWebSettings::PluginsEnabled to true. Could it not be finding the location of the flash .dll plugin file? I'm using Windows 10 and QT 5.3.

    1. Yes, it can be. Also check if you have installed NPAPI version of Flash plugin, it's not a default download option on Windows.

  3. Is the necessary changes have upstreamed ? In the github repo, it says that "This branch is 1099 commits ahead, 7251 commits behind WebKit:master." - which suggests that this new effort is already far from the upstream? Are you working on full time ? Or what will ensure, that these - otherwise very welcomed - development would stall, and fade away again? It must be huge work to keep up with WebKit, otherwise why would the qt project abandoned their effort 5 years ago?
    Otherwise, nice work, thanks for your effort!

    1. >Is the necessary changes have upstreamed?

      Yes, I am WebKit Committer and try to upstream all relevant changes when I have time to do it. Right now I'm focused on getting feature complete release, so some upstreaming activities were postponed.

      >This branch is 1099 commits ahead, 7251 commits behind WebKit:master.

      1. WebKit is moving very fast and 7251 commits behind is not such a large gap.

      2. qtwebkit-stable branch is based on the same branch as WebKitGTK 2.12.x, so it lags behind trunk by exactly same number of commits

      3. WebKit will be updated after feature-complete release is finished

      >Are you working on full time?


      >It must be huge work to keep up with WebKit

      Not really. It's a huge work to update after three-years break, especially if you don't know much about WebKit internals like it was with me in the beginning, but dealing with changes in incremental manner is much much easier.

      >otherwise why would the qt project abandoned their effort 5 years ago

      Not 5 but 3 years ago actually. IMO it was a combination of executive meddling and failure to find efficient development process. If we had the same man power as it was available for QtWebKit project 3 years ago, current work would have been done in much shorter time.

  4. This is very exciting! We have tried using QWebEngine but it is too slow! I tried using the download with my windows Qt5.6.1-1 installation but it would crash... So looking forward to a another release, see if that works.
    Are you the only on working on this?

    1. Like file name says, this binary is intended for use with Qt 5.7 (using VS 2015 compiler in 64 bit mode).

      We are working on integration of QtWebKit into Qt continuous integration system, that will allow to support different Qt versions and, in perspective, be released as Qt SDK component.

    2. Missed that, tried it with 5.7 and works great.
      One question I have is what licensing is needed to use this version of QtWebKit?
      Thanks for bringing this back to life!

  5. Wow! Great news! Good luck to you getting QtWebkit up and running again!
    I was really surprised recently when someone has fixed bug I have reported to QtWebkit 3 years ago. I even wanted to add comment to the ticket and ask "Hey guys! What are you doing? Isn't QtWebkit dead?" but failed to login to bugtracker...

  6. QtWebKit rocks, WebEngine/Blink is just a bloated mess.

  7. Any ETA on a Beta?
    QWebEngine is just not cutting it, this would really be welcomed!