Qt WebEngine Features

Summarizes Qt WebEngine features.

Qt WebEngine supports the following features:

Audio and Video Codecs

Qt WebEngine supports the MPEG-4 Part 14 (MP4) file format only if the required proprietary audio and video codecs, such as H.264 and MPEG layer-3 (MP3), have been enabled. Proprietary codecs can be enabled by passing the following option to the configure tool when configuring Qt:

-webengine-proprietary-codecs

For example, the following option could be passed when configuring Qt for building it at the top level:

configure -webengine-proprietary-codecs

For more information, see Qt Configure Options.

When using cmake to build just the Qt WebEngine module, the following command can be used to configure and build (in this example, the Qt WebEngine source code is located in C:\qt\qtwebengine):

qt-configure-module C:\qt\qtwebengine -webengine-proprietary-codecs
cmake --build . --parallel

Warning

When distributing proprietary codec libraries, you must acquire licenses for them.

FFmpeg is a cross-platform solution to record, convert, and stream audio and video. It can be configured for use with several codecs, which rises licensing issues during distribution with the codec libraries. For some codecs, open source implementations, such as OpenH264 , are available.

WebEngineDriver

With WebEngineDriver, you can automate the testing of web sites across browsers. WebEngineDriver is based on ChromeDriver and can be used the same way. For more information about ChromeDriver and its use, visit ChromeDriver user site .

WebEngineDriver has slight modifications compared to ChromeDriver to be able to connect to Qt WebEngine based browsers. It is compatible with Qt WebEngine example browsers, such as Simple Browser or Nano Browser .

The browser automation is scripted through a WebDriver client like the Selenium WebDriver . For example, WebEngineDriver can be used with the Python lanugage bindings of Selenium WebDriver:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service

service = Service(executable_path='QTDIR/libexec/webenginedriver')
options = webdriver.ChromeOptions()
options.binary_location = 'path/to/browser_binary'

driver = webdriver.Chrome(service=service, options=options)
driver.get("http://www.google.com/")
driver.quit()

In this example,

  • executable_path has to be set to the WebEngineDriver’s binary path

  • QTDIR is the directory where Qt is installed

  • options.binary_location has to be set to the browser’s binary path

Note

On Windows: executable_path='QTDIR/bin/webenginedriver.exe'

Before executing the script, the QTWEBENGINE_REMOTE_DEBUGGING environment variable has to be set. Its value is a port number what is used by both the browser and WebEngineDriver to communicate with each other.

export QTWEBENGINE_REMOTE_DEBUGGING=12345

By executing, the script opens the specified web browser and loads the Google web site.

WebEngineDriver can be also attached to an already running browser if it was started with the remote debugging port set. options.debugger_address has to be set to the remote debugging address in the script:

options.debugger_address = 'localhost:12345'

In this case, options.binary_location should not be set because the browser is already running. The environment variable QTWEBENGINE_REMOTE_DEBUGGING is not used by the WebEngineDriver if options.debugger_address is set.

Note

WebEngineDriver must be built with the same version of Chromium as Qt WebEngine is using.

Chromium DevTools

The Chromium DevTools provide the ability to inspect and debug layout and performance issues of any web content.

This feature can be tested by launching a Qt WebEngine application with the command line option --remote-debugging-port=[your-port] or by setting the environment variable QTWEBENGINE_REMOTE_DEBUGGING and then using a Chromium based browser (such as Simple Browser or Nano Browser ) to connect to http://localhost:[your-port].

Note

Any WebEngine command line options should be specified after the --webEngineArgs option, which is used to separate the user’s application specific options from the WebEngine ‘s ones.

--webEngineArgs --remote-debugging-port=5000

To avoid WebSocket errors during remote debugging, add an additional command-line argument --remote-allow-origins=<origin>[,<origin>, ...], where <origin> refers to the request origin. Use --remote-allow-origins=* to allow connections from all origins. If nothing is specified, Qt WebEngine will add --remote-allow-origins=* to command-line arguments when remote-debugging is enabled, thereby allowing requests from all origins.

The Chromium DevTools page can also be shown within the application. To set this up, you can call either setInspectedPage() to the page to be inspected, which implicitly loads the DevTools into the this page, or setDevToolsPage() to let the this page be inspected.

The respective QML properties are WebEngineView.devToolsView and WebEngineView.inspectedView .

For more information, see Qt WebEngine Debugging and Profiling .

Client Certificates

Some web servers, in particular many intranet sites, require the client to authenticate itself with a certificate, called a client certificate. Qt WebEngine will read the client certificates installed in the system settings in macOS and Windows, and on Linux those installed into the NSS database. Certificates can be installed into the NSS database using the pk12util tool.

By default, Qt WebEngine will not offer any client certificates to servers, as doing so uniquely identifies the user and might violate privacy expectations.

To activate support for client certificates, an application needs to listen to the selectClientCertificate or selectClientCertificate signals and select one of the offered certificates. For applications that can navigate to untrusted web sites, it is recommended to always give the user a choice before uniquely identifying them to a remote server.

In addition to the client certificate stored in system settings, Qt WebEngine offers also the in-memory store. The QWebEngineClientCertificateStore instance can be obtained with the clientCertificateStore() method. An application can use this class to add a new certificate with a add() call. Note that during the selectClientCertificate calls, Qt WebEngine lists both system and in-memory stored clients certificates.

See also Client Certificate Example for more implementation details.

Custom Schemes

Qt WebEngine makes it possible for the application to define its own custom URL schemes with specialized security policies and transport mechanisms.

Custom schemes can be used to implement alternative network protocols with all the usual web security policies, privileged internal schemes for displaying user interface components or debugging information, sandboxed schemes with extra restrictions, and so on.

For more information, see QWebEngineUrlScheme and QWebEngineUrlSchemeHandler .

Drag and Drop

Qt WebEngine supports HTML5 drag and drop.

This feature can be tested by opening an HTML5 drag and drop demo, such as HTML5 Demos - Drag and Drop , HTML5 Demos - Simple Drag and Drop , or HTML5 Demos - Drag and Drop, Automatic Upload , in Simple Browser or Nano Browser .

Dragging files into the browser is not actually part of HTML5, but it is supported. It can be tested by opening HTML5 Demos - File API .

Support for this feature was added in Qt 5.7.0.

Favicon

Qt WebEngine supports the web site URL icon, favicon. Each icon is stored in the internal database for each QWebEngineProfile and can be accessed using a icon() call or a WebEngineView.icon property for the currently loaded content.

Moreover Qt WebEngine provides API for accessing already stored icons in the internal profile’s database.

Note

The icon database is not available for off-the-record profiles.

QML Favicon Handling

For accessing icons a QQuickImageProvider is registered. This provider can be accessed by a special URL where the scheme is “image:” and the host is “favicon”.

The url can be the URL of the favicon:

The url also can be a page URL to access its icon:

If more than one icon is available, the Image::sourceSize property can be specified to choose the icon with the desired size. If Image::sourceSize is not specified or 0, the largest available icon will be chosen.

The image provider looks up the requested icon in the existing WebEngineView instances. First, it tries to match the currently displayed icons. If no match has been found it requests the icon from the database. Each profile has its own icon database and it is stored in the persistent storage thus the stored icons can be accessed without network connection too. The icon must be previously loaded to be stored in the database.

C++ Favicon Handling

A user can request an icon from the previously loaded content for each QWebEngineProfile using the requestIconForPageURL() or requestIconForIconURL() calls. Note that the profile’s database is stored in the persistent storage and can be accessed without a network connection.

Fullscreen

Qt WebEngine supports viewing web content in fullscreen mode. For more information, see WebEngineSettings.fullscreenSupportEnabled , fullScreenRequested , FullScreenSupportEnabled , and fullScreenRequested .

This feature can be tested by playing a video from YouTube in Video Player or Nano Browser , and clicking the full screen icon to go into fullscreen mode.

Support for this feature was added in Qt 5.6.0.

Hardware Acceleration

QtWebEngine tries to use hardware acceleration for rendering the content. It uses OpenGL or OpenGLES APIs to execute rendering calls on the GPU. As a fallback, software rendering is used whenever the hardware does not meet the required set of OpenGL functionality. A user can check the current hardware acceleration state by loading the chrome://gpu internal page. Moreover, the acceleration can be explicitly disabled with QTWEBENGINE_CHROMIUM_FLAGS using the disable-gpu switch. For example on Linux:

export QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu

HTML5 DRM

Qt WebEngine supports viewing DRM protected videos if the Widevine CDM plugin has been installed. CDM plugin is a replacement of Flash based plugins for displaying DRM-protected content. It comes only in a binary format, so it can hide DRM decryption implementation details. It can be obtained from a third party or from a Google Chrome installation.

Qt WebEngine on startup looks for the Widevine CDM plugin in well know locations, like default Google Chrome installation directory or Linux distro specific paths. However, plugin location can be also passed with QTWEBENGINE_CHROMIUM_FLAGS using widevine-path.

On Windows:

set QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="C:/some path/widevinecdm.dll"

On Linux:

export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.so"

On macOS:

export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.dylib"

The video format most commonly used by DRM services, H.264, requires proprietary audio and video codecs. For more information about enabling the codecs, see Audio and Video Codecs .

This feature can be tested by playing a video in Simple Browser or Nano Browser from castLabs , Swank Motion Pictures, Inc. , or Bitmovin Player .

Support for this feature was added in Qt 5.7.0.

HTML5 Geolocation

Qt WebEngine supports JavaScript Geolocation API with Qt Positioning as a backend. HTML5 geolocation is disabled by default. To explicitly allow it, the application needs to listen to permissionRequested . When a permission request with a type of Geolocation is received, you can call grant() on the received object to grant the required permission.

If Qt WebEngine was built with Qt Positioning support then this feature can be tested by using Maps and allowing it to find the current position of the user.

Note

On Windows 11, enable settings to grant the maps example access to Windows location services. In the Settings App under Privacy & Security > Location, enable Location services, Let apps access your location and Let desktop apps access your location.

See Qt Positioning for a possible backend setup like the GPS or IP based positioning.

Support for this feature was added in Qt 5.5.0.

HTML5 WebSockets

Qt WebEngine supports the WebSocket JavaScript API to communicate with WebSocket servers using the ws:// or wss:// protocols. Moreover, integration with Qt WebChannel and Qt WebSockets enables communication between JavaScript and the native side of the application.

The Qt WebChannel module has a great example for a chat server and its web based chat client. The client works out of the box in the example browsers of Qt WebEngine (such as Simple Browser or Nano Browser ).

HTTP/2 Protocol

Qt WebEngine supports the Chromium implementation of the HTTP/2 protocol.

This feature can be tested by opening an HTTP/2 demo, such as the Akamai HTTP/2 Demo , in Simple Browser or Nano Browser .

Local Storage

Qt WebEngine supports saving key-value pairs in a Local Storage with no expiration date. This is a part of the Web Storage API , where a user can access a Storage object for the given domains using the Window.localStorage JavaScript property. The stored data will persist even after the page or the browser application is closed.

Note that the Local Storage can be also disabled with a LocalStorageEnabled setting. Moreover, the storage path can be adjusted with a setPersistentStoragePath call.

QWebEngineProfile profile("MyProfile");
profile.settings()->setAttribute(QWebEngineSettings::LocalStorageEnabled, isEnabled);
profile.setPersistentStoragePath("/path/to/storage");

Qt WebEngine offers also an easy way of investigating the content of the Local Storage with Qt WebEngine Developer Tools by visiting the Application panel and expanding the Local Storage menu.

Native Dialogs

A web page might request dialogs for the following functions:

  • Entering user credentials for HTTP and proxy authentication

  • Displaying JavaScript alerts, confirmation dialogs, and prompts

  • Picking colors

  • Selecting files

  • Displaying form validation messages

Qt WebEngine provides standard dialogs for these functions. In widget-based applications, the standard dialogs are based on QDialog, whereas in Qt Quick applications, they can be based either on Qt Quick Controls 1 or Qt Quick Controls 2 (since Qt 5.8). The latter are used only on eglfs platforms.

To explicitly force either dialogs based on Qt Quick Controls 1 or Qt Quick Controls 2, set the QTWEBENGINE_DIALOG_SET environment variable to either QtQuickControls1 or QtQuickControls2.

Qt WebEngine Widgets dialogs can be customized by reimplementing the chooseFiles() , javaScriptAlert() , javaScriptConfirm() , and javaScriptPrompt() functions.

Since Qt 5.8, Qt Quick dialogs can be customized by connecting to the authenticationDialogRequested() , javaScriptDialogRequested() , colorDialogRequested() , fileDialogRequested() , and WebEngineView::formValidationMessageRequested() signals. For an example,

PDF File Viewing

Qt WebEngine supports viewing PDF documents by navigating to them. This feature uses the Chromium extensions API and PDF viewer plugin to display the PDF documents. It can be tested in Simple Browser or Nano Browser .

Loading plugins needs to be enabled using PluginsEnabled or WebEngineSettings::pluginsEnabled in order to use this feature.

This feature can be turned on (default) or off via the PdfViewerEnabled or WebEngineSettings::pdfViewerEnabled setting.

Support for this feature was added in Qt 5.13.0.

Page Lifecycle API

Qt WebEngine supports the Page Lifecycle API specification , a work-in-progress extension to the HTML standard for allowing user agents to reduce their resource consumption by freezing or discarding background pages. The feature is exposed both in the Widgets and QML APIs.

For an example of the QML API in use, see the WebEngine Lifecycle Example .

Support for this feature was added in Qt 5.14.0.

Overview of Lifecycle States

Each WebEngineView item (or QWebEnginePage object) can be in one of three lifecycle states: active, frozen, or discarded. These states, like the sleep states of a CPU, control the resource usage of web views.

The active state is the normal, unrestricted state of a web view. All visible web views are always in the active state, as are all web views that have not yet finished loading. Only invisible, idle web views can be transitioned to other lifecycle states.

The frozen state is a low CPU usage state. In this state, most HTML task sources are suspended (frozen) and, as a result, most DOM event processing and JavaScript execution will also be suspended. The web view must be invisible in order to be frozen as rendering is not possible in this state.

The discarded state is an extreme resource-saving state. In this state, the browsing context of the web view will be discarded and the corresponding renderer subprocess shut down. CPU and memory usage in this state is reduced virtually to zero. On exiting this state the web page will be automatically reloaded. The process of entering and exiting the discarded state is similar to serializing the browsing history of the web view and destroying the view, then creating a new view and restoring its history.

See also WebEngineView::LifecycleState . The equivalent in the Widgets API is LifecycleState .

The `` lifecycleState``

and `` recommendedState``

Properties

The lifecycleState property of the WebEngineView type is a read-write property that controls the current lifecycle state of the web view. This property is designed to place as few restrictions as possible on what states can be transitioned to. For example, it is allowed to freeze a web view that is currently playing music in the background, stopping the music. In order to implement a less aggressive resource-saving strategy that avoids interrupting user-visible background activity, the recommendedState property must be used.

The recommendedState property of the WebEngineView type is a read-only property that calculates a safe limit on the lifecycleState property, taking into account the current activity of the web view. So, in the example of a web view playing music in the background, the recommended state will be Active since a more aggressive state would stop the music. If the application wants to avoid interrupting background activity, then it should avoid putting the web view into a more aggressively resource-saving lifecycle state than what’s given by recommendedState .

See also WebEngineView::lifecycleState and WebEngineView::recommendedState . The equivalents in the Widgets API are lifecycleState and recommendedState .

The DOM Extensions

The lifecycleState property is connected to the Page Lifecycle API specification , which specifies two new DOM events, freeze and resume, and adds a new Document.wasDiscarded boolean property. The freeze and resume events are fired when transitioning from the Active to the Frozen state, and vice-versa. The Document.wasDiscarded property is set to true when transitioning from the Discarded state to the Active state.

Process Models

Qt WebEngine uses multiple OS processes to isolate web sites from each other and from the client application, improving security and robustness. The following process models, or ways to divide web sites between OS processes, are supported:

Process per Site Instance

This is the default model. Pages from separate sites are put into separate processes and separate visits to the same site are also isolated.

Two web pages are considered as belonging to the same site if they originate from the same registered domain name (for example, wikipedia.org) and scheme (for example, https). This is similar to the same-origin policy but subdomains are ignored. For example, both https://en.wikipedia.org/ and https://de.wikipedia.org/ would belong to the same site.

A site instance is a collection of web pages belonging to the same site. When the application explicitly loads a URL into Qt WebEngine (via setUrl , for example), a new site instance is created for the page. However, when the user clicks same-site links on the page, the existing site instance is merely extended with more pages.

For instance, in the Simple Browser example, when a user opens two tabs and explicitly enters https://en.wikipedia.org/ into the URL bars, both tabs will have their own separate OS processes (because explicitly entering a URL creates a new site instance). However, when the user then middle-clicks some same-site links to open more tabs, these new tabs will share the same OS process (because user interaction extends the existing site instance).

Process per Site

Pages from separate sites are put into separate processes. Unlike Process per Site Instance, all visits to the same site will share an OS process.

The benefit of this model is reduced memory consumption, because more web pages will share processes. The drawbacks include reduced security, robustness, and responsiveness.

To enable this model, use the command-line argument --process-per-site. See Using Command-Line Arguments .

Single Process

For debugging purposes only, a single process mode can be enabled using the command-line argument --single-process. See Using Command-Line Arguments and Qt WebEngine Debugging and Profiling .

Spellchecker

Qt WebEngine supports integrating spellchecking support into HTML forms to enable users to submit spellchecked messages. When the user clicks on an underlined misspelled word, the default context menu displays up to four suggestions. Selecting one will replace the misspelled word.

To be able to check the spelling, the spellchecker needs dictionaries. It supports dictionaries from the Hunspell project , but they have to be compiled into a special binary format. A Hunspell dictionary consists of two files:

  • A .dic file that is a dictionary containing words for the language

  • An .aff file that defines the meaning of special flags in the dictionary

These two files can be converted into the bdic format by using the qwebengine_convert_dict tool that is shipped together with Qt. When the Qt WebEngine spellchecker initializes, it will try to load the bdict dictionaries and to check them for consistency.

If QTWEBENGINE_DICTIONARIES_PATH is set, the spellchecker uses the dictionaries in the specified directory without looking anywere else. Otherwise, it uses the qtwebengine_dictionaries directory relative to the executable if it exists. If it does not exist, it will look in QT_INSTALL_PREFIX/qtwebengine_dictionaries.

On macOS, depending on how Qt WebEngine is configured at build time, there are two possibilities how spellchecking data is found:

  • Hunspell dictionaries (default) - .bdic dictionaries are used, just like on other platforms

  • Native dictionaries - the macOS spellchecking APIs are used (which means the results will depend on the installed OS dictionaries)

Thus, in the macOS Hunspell case, Qt WebEngine will look in the qtwebengine_dictionaries subdirectory located inside the application bundle Resources directory, and also in the Resources directory located inside the Qt framework bundle.

To summarize, in case of Hunspell usage, the following paths are considered:

  • QTWEBENGINE_DICTIONARIES_PATH, if set

  • QCoreApplication::applicationDirPath()/qtwebengine_dictionaries or QCoreApplication::applicationDirPath()/../Contents/Resources/qtwebengine_dictionaries (on macOS)

  • [QLibraryInfo::DataPath]/qtwebengine_dictionaries or path/to/ QtWebEngineCore .framework/Resources/qtwebengine_dictionaries (Qt framework bundle on macOS)

Spellchecking is disabled by default and can be enabled per profile by using the setSpellCheckEnabled() method in widget-based applications and the spellCheckEnabled property in Qt Quick applications.

The current language used for spellchecking is defined per profile, and can be set using the setSpellCheckLanguages() method or the spellCheckLanguages property.

This feature can be tested by building and running the Spellchecker Example .

Qt WebEngine can be compiled also without spellchecker support with the use of a webengine-spellchecker configure switch.

qt-configure-module path\to\qtwebengine\sources -no-webengine-spellchecker

For more information, see Qt Configure Options.

Support for this feature was added in Qt 5.8.0.

Touch

Qt WebEngine supports touch devices for navigating and interacting with web pages.

Applications can prohibit the use of touch events in the following ways:

  • Passing the flag --touch-events=disabled on the command line will disable touch event support in JavaScript API (meaning ontouchstart and related handlers will not be present in the document.window object). Touch events will still be delivered to web pages.

  • Installing an event filter object using QObject::installEventFilter on the WebEngine view focus proxy object, and filtering out all touch events.

View Source

Qt WebEngine supports viewing the HTML source of a web page.

This feature can be used from custom menus or assigned to custom events. For more information, see WebEngineView::WebAction , and WebAction .

This feature can be tested by opening a web page in Simple Browser or Nano Browser , and then selecting Page Source in the context menu. The Page Source context menu entry opens the source view in a new tab.

For opening the source view in the current tab, URLs with view-source URI scheme are also supported. For example, you can type the following URL to the URL bar to view the HTML source of the qt.io web page:

view-source:https://www.qt.io/

Auto-completion of incomplete URLs with view-source URI scheme makes the usage of this feature more comfortable. For example, the following incomplete URL also loads the source view of the qt.io web page:

view-source:qt.io

Support for this feature was added in Qt 5.8.0.

Web Notifications

Qt WebEngine supports JavaScript Web Notifications API . The application has to explicitly allow the feature by using QWebEnginePage::Notifications or WebEngineView.Notifications .

Support for this feature was added in Qt 5.13.0.

WebGL

Qt WebEngine supports WebGL for some graphics stacks setups. A user can visit the chrome://gpu page using the QtWebEngine powered application. The Graphics Feature Status overview states if WebGL is supported for the current platform setup. A user can also check the WebGL Report .

The WebGL support is enabled by default. You can disable it with the WebGLEnabled setting.

WebRTC

WebRTC provides browsers with Real-Time Communications (RTC) capabilities via simple APIs. For more information, see WebEngineView.Feature , and QWebEnginePage::Feature.

This feature can be tested by setting up a webcam or microphone and then opening https://test.webrtc.org/ in Simple Browser or Nano Browser .