diff options
Diffstat (limited to 'src/webengine/doc/src/qtwebengine-features.qdoc')
| -rw-r--r-- | src/webengine/doc/src/qtwebengine-features.qdoc | 644 |
1 files changed, 0 insertions, 644 deletions
diff --git a/src/webengine/doc/src/qtwebengine-features.qdoc b/src/webengine/doc/src/qtwebengine-features.qdoc deleted file mode 100644 index 431367765..000000000 --- a/src/webengine/doc/src/qtwebengine-features.qdoc +++ /dev/null @@ -1,644 +0,0 @@ -/**************************************************************************** -** -** Copyright (C) 2019 The Qt Company Ltd. -** Contact: https://www.qt.io/licensing/ -** -** This file is part of the documentation of the Qt Toolkit. -** -** $QT_BEGIN_LICENSE:FDL$ -** Commercial License Usage -** Licensees holding valid commercial Qt licenses may use this file in -** accordance with the commercial license agreement provided with the -** Software or, alternatively, in accordance with the terms contained in -** a written agreement between you and The Qt Company. For licensing terms -** and conditions see https://www.qt.io/terms-conditions. For further -** information use the contact form at https://www.qt.io/contact-us. -** -** GNU Free Documentation License Usage -** Alternatively, this file may be used under the terms of the GNU Free -** Documentation License version 1.3 as published by the Free Software -** Foundation and appearing in the file included in the packaging of -** this file. Please review the following information to ensure -** the GNU Free Documentation License version 1.3 requirements -** will be met: https://www.gnu.org/licenses/fdl-1.3.html. -** $QT_END_LICENSE$ -** -****************************************************************************/ - -/*! - \page qtwebengine-features.html - \title Qt WebEngine Features - - \brief Summarizes \QWE features. - - \QWE supports the following features: - - \list - \li \l{Audio and Video Codecs} - \li \l{Chromium DevTools} - \li \l{Client Certificates} - \li \l{Custom Schemes} - \li \l{Drag and Drop} - \li \l{Fullscreen} - \li \l{HTML5 DRM} - \li \l{HTML5 Geolocation} - \li \l{HTTP/2 Protocol} - \li \l{Native Dialogs} - \li \l{Pepper Plugin API} - \li \l{PDF File Viewing} - \li \l{Page Lifecycle API} - \li \l{Print to PDF} - \li \l{Process Models} - \li \l{Spellchecker} - \li \l{Touch} - \li \l{View Source} - \li \l{webrtc_feature}{WebRTC} - \li \l{Web Notifications} - \endlist - - \section1 Audio and Video Codecs - - \QWE 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 \c configure tool when configuring Qt: - - \code - -webengine-proprietary-codecs - \endcode - - For example, the following option could be passed when configuring Qt for - building it at the top level: - - \code - configure -webengine-proprietary-codecs - \endcode - - For more information, see \l{Qt Configure Options}. - - When using qmake to build just the \QWE module, the following - command can be used (in this example, the \QWE source code is - located in \c {C:\qt\qtwebengine}): - - \code - qmake C:\qt\qtwebengine -- -webengine-proprietary-codecs - \endcode - - \warning When distributing proprietary codec libraries, you must acquire - licenses for them. - - \l 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 \l{OpenH264 Project Homepage} - {OpenH264}, are available. - - \section1 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 \QWE application with the - command line option \c {--remote-debugging-port=[your-port]} or by setting - the environment variable \c QTWEBENGINE_REMOTE_DEBUGGING, and then using a - Chromium based browser (such as \l{WebEngine Widgets Simple Browser Example} - {Simple Browser} or \l{WebEngine Quick Nano Browser}{Nano Browser}) to connect - to \c {http://localhost:[your-port]}. - - The Chromium DevTools page can also be shown within the application. To set - this up, you can call either QWebEnginePage::setInspectedPage() to the page - to be inspected, which implicitly loads the DevTools into the \c this page, - or QWebEnginePage::setDevToolsPage() to let the \c this page be inspected. - - The respective QML properties are \l{WebEngineView::devToolsView} - {WebEngineView.devToolsView} and \l{WebEngineView::inspectedView} - {WebEngineView.inspectedView}. - - For more information, see \l {Qt WebEngine Debugging and Profiling}. - - \section1 Client Certificates - - Some web servers, in particular many intranet sites, require the client to - authenticate itself with a certificate, called a \e {client certificate}. \QWE - 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 \c pk12util tool. - - By default, \QWE 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 QWebEnginePage::selectClientCertificate or - \l{WebEngineView::selectClientCertificate}{WebEngineView.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. - - \section1 Custom Schemes - - \QWE 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 compoments or debugging information, sandboxed - schemes with extra restrictions, and so on. - - For more information, see \l QWebEngineUrlScheme and \l - QWebEngineUrlSchemeHandler. - - \section1 Drag and Drop - - \QWE supports HTML5 drag and drop. - - This feature can be tested by opening an HTML5 drag and drop demo, such as - \l{HTML5 Demos - Drag and Drop}, \l{HTML5 Demos - Simple Drag and Drop}, or - \l{HTML5 Demos - Drag and Drop, Automatic Upload}, in \l{WebEngine Widgets - Simple Browser Example}{Simple Browser} or \l{WebEngine Quick Nano Browser} - {Nano Browser}. - - Dragging files into the browser is not actually part of HTML5, but it is - supported. It can be tested by opening \l{HTML5 Demos - File API}. - - Support for this feature was added in Qt 5.7.0. - - \section1 Fullscreen - - \QWE supports viewing web content in fullscreen mode. For more - information, see \l{WebEngineSettings::fullscreenSupportEnabled} - {WebEngineSettings.fullscreenSupportEnabled}, - \l{WebEngineView::fullScreenRequested}{WebEngineView.fullScreenRequested}, - QWebEngineSettings::FullScreenSupportEnabled, and - QWebEnginePage::fullScreenRequested. - - This feature can be tested by playing a video from YouTube in \l{WebEngine - Widgets Video Player Example}{Video Player} or \l{WebEngine Quick Nano Browser} - {Nano Browser}, and clicking the full screen icon to go into fullscreen - mode. - - Support for this feature was added in Qt 5.6.0. - - \section1 HTML5 DRM - - \QWE supports viewing DRM protected videos if the \l{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. - - \QWE on startup looks for the \l{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 \c {QTWEBENGINE_CHROMIUM_FLAGS} using \c {widevine-path}. - - On Windows: - \code - set QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="C:/some path/widevinecdm.dll" - \endcode - - On Linux: - \code - export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.so" - \endcode - - On macOS: - \code - export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.dylib" - \endcode - - - 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 \l{Audio and Video Codecs}. - - This feature can be tested by playing a video in \l{WebEngine Widgets Simple Browser - Example}{Simple Browser} or \l{WebEngine Quick Nano Browser}{Nano Browser} - from \l{castLabs}, \l{Swank Motion Pictures, Inc.}, or \l{Bitmovin Player}. - - Support for this feature was added in Qt 5.7.0. - - \section1 HTML5 Geolocation - - \QWE supports JavaScript Geolocation API with \l {Qt Location} as a - backend. The application has to explicitly allow the feature by using - QWebEnginePage::Geolocation or \l{WebEngineView::Feature} - {WebEngineView.Feature}. - - If Qt Location has been built before \QWE then this feature can be - tested by using \l{WebEngine Widgets Maps Example}{Maps} and allowing it to - find the current position of the user. Note that on Windows an external GPS - receiver must be connected to the application. For more information, see - \l{Qt Positioning}. - - Support for this feature was added in Qt 5.5.0. - - \section1 HTTP/2 Protocol - - \QWE supports the Chromium implementation of the \l{HTTP/2} - protocol. - - This feature can be tested by opening an HTTP/2 demo, such as the - \l{Akamai HTTP/2 Demo}, in \l{WebEngine Widgets Simple Browser Example} - {Simple Browser} or \l{WebEngine Quick Nano Browser}{Nano Browser}. - - \section1 Native Dialogs - - A web page might request dialogs for the following functions: - - \list - \li Entering user credentials for HTTP and proxy authentication - \li Displaying JavaScript alerts, confirmation dialogs, and prompts - \li Picking colors - \li Selecting files - \li Displaying form validation messages - \endlist - - \QWE 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 \c eglfs platforms. - - To explicitly force either dialogs based on Qt Quick Controls 1 or Qt Quick - Controls 2, set the \c QTWEBENGINE_DIALOG_SET environment variable to either - \c{QtQuickControls1} or \c{QtQuickControls2}. - - \QWE Widgets dialogs can be customized by reimplementing the - QWebEnginePage::chooseFiles(), QWebEnginePage::javaScriptAlert(), - QWebEnginePage::javaScriptConfirm(), and QWebEnginePage::javaScriptPrompt() - functions. - - Since Qt 5.8, Qt Quick dialogs can be customized by connecting to the - WebEngineView::authenticationDialogRequested(), - WebEngineView::javaScriptDialogRequested(), - WebEngineView::colorDialogRequested(), - WebEngineView::fileDialogRequested(), and - WebEngineView::formValidationMessageRequested() signals. For an example, - see \l{WebEngine Qt Quick Custom Dialogs Example}. - - \section1 Pepper Plugin API - - \QWE supports loading Pepper Plugin API (PPAPI) plugins if - WebEngineSettings::pluginsEnabled or QWebEngineSettings::PluginsEnabled - is set. - - Except for the Adobe Flash Player plugin, the plugins must be loaded - manually using the Chromium command line syntax with the - \c --register-pepper-plugins argument. The argument value is a list of - entries, separated by commas, that contain the file path and one or several - MIME types, separated by semicolons: - - \code - <file-path-plugin1>;<mime-type-plugin1>,<file-path-plugin2>;<mime-type1-plugin2>;<mime-type2-plugin2> - \endcode - - For example: - - \code - --register-pepper-plugins="libppapi_example.so;application/x-ppapi-example" - \endcode - - The MIME type is important because it determines which embeds the plugin is - used for. - - Support for this feature was added in Qt 5.6.0. - - \section2 Pepper Flash Player Plugin Support - - The Pepper Flash player plugin can be loaded automatically if it is - installed in one of the following locations, depending on the platform: - - \list - \li Windows - \code - C:\Windows\SysWOW64\Macromed\Flash\pepflashplayer*.dll - C:\Windows\System32\Macromed\Flash\pepflashplayer*.dll - \endcode - \li OS X - \code - /Library/Internet Plug-Ins/PepperFlashPlayer/PepperFlashPlayer.plugin - \endcode - \li Linux - \code - /usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so - /usr/lib/adobe-flashplugin/libpepflashplayer.so - /usr/lib/PepperFlash/libpepflashplayer.so - /usr/lib64/chromium/PepperFlash/libpepflashplayer.so - \endcode - \endlist - - You can also load the Pepper Flash player from a specific location by using - command line arguments: - - \code - --ppapi-flash-path=./libpepflashplayer.so - \endcode - - By default, the Flash version is set to \c{11.2.999.999}. You can use the - \c{ppapi-flash-version=} argument to set another Flash version in the - format \c{major.minor.build.revision}: - - \code - --ppapi-flash-version=16.0.0.235 - \endcode - - This feature can be tested in \l{WebEngine Widgets Simple Browser Example}{Simple Browser} - or \l{WebEngine Quick Nano Browser}{Nano Browser} if the Adobe Flash PPAPI - plugin is installed and plugins are enabled in the browser. To test the - feature, the \c https://helpx.adobe.com/flash-player.html page can be opened - in the browser. - - \section1 PDF File Viewing - - \QWE 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 \l{WebEngine Widgets Simple Browser Example}{Simple Browser} or - \l{WebEngine Quick Nano Browser}{Nano Browser}. - - Loading plugins needs to be enabled using QWebEngineSettings::PluginsEnabled or - WebEngineSettings::pluginsEnabled in order to use this feature. - - This feature can be turned on (default) or off via the QWebEngineSettings::PdfViewerEnabled or - WebEngineSettings::pdfViewerEnabled setting. - - Support for this feature was added in Qt 5.13.0. - - \section1 Page Lifecycle API - - \QWE supports the \l {https://wicg.github.io/page-lifecycle/spec.html}{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 \l {WebEngine Lifecycle - Example}. - - Support for this feature was added in Qt 5.14.0. - - \section2 Overview of Lifecycle States - - Each \l {WebEngineView} item (or \l {QWebEnginePage} object) can be in one - of three \e {lifecycle states}: active, frozen, or discarded. These states, - like the sleep states of a CPU, control the resource usage of web views. - - The \e {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 \e {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 \e {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 \l {WebEngineView::LifecycleState}. The equivalent in the Widgets - API is \l {QWebEnginePage::LifecycleState}. - - \section2 The \c {lifecycleState} and \c {recommendedState} Properties - - The \l {WebEngineView::}{lifecycleState} property of the \l {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 \l - {WebEngineView::} {recommendedState} property must be used. - - The \l {WebEngineView::}{recommendedState} property of the \l - {WebEngineView} type is a read-only property that calculates a safe limit on - the \l {WebEngineView::}{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 \c {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 \l {WebEngineView::}{recommendedState}. - - See also \l {WebEngineView::lifecycleState} and \l - {WebEngineView::recommendedState}. The equivalents in the Widgets API are \l - {QWebEnginePage::lifecycleState} and \l {QWebEnginePage::recommendedState}. - - \section2 The DOM Extensions - - The \l {WebEngineView::}{lifecycleState} property is connected to the \l - {https://wicg.github.io/page-lifecycle/spec.html}{Page Lifecycle API - specification}, which specifies two new DOM events, \c {freeze} and \c - {resume}, and adds a new \c {Document.wasDiscarded} boolean property. The \c - {freeze} and \c {resume} events are fired when transitioning from the \c - {Active} to the \c {Frozen state}, and vice-versa. The \c - {Document.wasDiscarded} property is set to \c {true} when transitioning from - the \c {Discarded} state to the \c {Active} state. - - \section1 Print to PDF - - \QWE supports printing a web page to a PDF file. For more - information, see QWebEnginePage::printToPdf() and - \l{WebEngineView::printToPdf}{WebEngineView.printToPdf}. - - This feature can be tested using \l{WebEngine Widgets Html2Pdf Example} - {Html2Pdf}. - - Support for this feature was added in Qt 5.7.0. - - \section1 Process Models - - \QWE 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: - - \list - \li \l{Process per Site Instance} - \li \l{Process per Site} - \li \l{Single Process} - \endlist - - \section2 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, \c wikipedia.org) and - scheme (for example, \c https). This is similar to the same-origin policy - but subdomains are ignored. For example, both \c{https://en.wikipedia.org/} - and \c{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 \QWE (via \l - QWebEnginePage::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 \l{WebEngine Widgets Simple Browser Example}{Simple - Browser} example, when a user opens two tabs and explicitly enters - \c{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). - - \section2 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 \c{--process-per-site}. - See \l{Using Command-Line Arguments}. - - \section2 Single Process - - For debugging purposes only, a single process mode can be enabled using the - command-line argument \c{--single-process}. See \l{Using Command-Line - Arguments} and \l{Qt WebEngine Debugging and Profiling}. - - \section1 Spellchecker - - \QWE 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 \l{Hunspell project}, but they have to be - compiled into a special binary format. A Hunspell dictionary consists of two - files: - - \list - - \li A \c .dic file that is a dictionary containing words for the - language - \li An \c .aff file that defines the meaning of special flags in the - dictionary - \endlist - - These two files can be converted into the \c bdic format by using the - \c qwebengine_convert_dict tool that is shipped together with Qt. - When the \QWE spellchecker initializes, it will try to load the - \c bdict dictionaries and to check them for consistency. - - If \c QTWEBENGINE_DICTIONARIES_PATH is set, the spellchecker uses the - dictionaries in the specified directory without looking anywere else. - Otherwise, it uses the \e qtwebengine_dictionaries directory relative to the - executable if it exists. If it does not exist, it will look in \c - QT_INSTALL_PREFIX/qtwebengine_dictionaries. - - On macOS, depending on how \QWE is configured at build time, there - are two possibilities how spellchecking data is found: - - \list - \li Hunspell dictionaries (default) - .bdic dictionaries are used, just - like on other platforms - \li Native dictionaries - the macOS spellchecking APIs are used (which - means the results will depend on the installed OS dictionaries) - \endlist - - Thus, in the macOS Hunspell case, \QWE will look in the \e - qtwebengine_dictionaries subdirectory located inside the application bundle - \c Resources directory, and also in the \c Resources directory located - inside the Qt framework bundle. - - To summarize, in case of Hunspell usage, the following paths are considered: - - \list - \li \c QTWEBENGINE_DICTIONARIES_PATH, if set - \li QCoreApplication::applicationDirPath()/qtwebengine_dictionaries - or QCoreApplication::applicationDirPath()/../Contents/Resources/qtwebengine_dictionaries - (on macOS) - \li [QLibraryInfo::DataPath]/qtwebengine_dictionaries - or path/to/QtWebEngineCore.framework/Resources/qtwebengine_dictionaries (Qt framework - bundle on macOS) - \endlist - - Spellchecking is disabled by default and can be enabled per profile by - using the QWebEngineProfile::setSpellCheckEnabled() method in widget-based - applications and the \l {QQuickWebEngineProfile::spellCheckEnabled} - {WebEngineProfile.spellCheckEnabled} property in Qt Quick applications. - - The current language used for spellchecking is defined per profile, and can - be set using the QWebEngineProfile::setSpellCheckLanguages() method or the - \l {QQuickWebEngineProfile::spellCheckLanguages} - {WebEngineProfile.spellCheckLanguages} property. - - This feature can be tested by building and running the - \l{WebEngine Widgets Spellchecker Example}{Spellchecker Example}. - - Support for this feature was added in Qt 5.8.0. - - \section1 Touch - - \QWE supports touch devices for navigating and interacting with web pages. - - Applications can prohibit the use of touch events in the following ways: - - \list - \li Passing the flag \c --touch-events=disabled on the command line will disable touch event - support in JavaScript API (meaning \c ontouchstart and related handlers will not be present - in the \c document.window object). Touch events will still be delivered to web pages. - - \li Installing an event filter object using \l {QObject::installEventFilter} on the WebEngine - view focus proxy object, and filtering out all touch events. - - \endlist - - \section1 View Source - - \QWE 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 QWebEnginePage::WebAction. - - This feature can be tested by opening a web page in \l{WebEngine Widgets - Simple Browser Example}{Simple Browser} or \l{WebEngine Quick Nano Browser} - {Nano Browser}, and then selecting \c{Page Source} in the context menu. The - \c{Page Source} context menu entry opens the source view in a new tab. - - For opening the source view in the current tab, URLs with \l{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: - \code - view-source:https://www.qt.io/ - \endcode - - Auto-completion of incomplete URLs with \l{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: - \code - view-source:qt.io - \endcode - - Support for this feature was added in Qt 5.8.0. - - \target webrtc_feature - \section1 WebRTC - - WebRTC provides browsers with Real-Time Communications (RTC) capabilities - via simple APIs. For more information, see \l{WebEngineView::Feature} - {WebEngineView.Feature} and QWebEnginePage::Feature. - - This feature can be tested by setting up a webcam or microphone and then - opening \c https://test.webrtc.org/ in \l{WebEngine Widgets Simple Browser - Example}{Simple Browser} or \l{WebEngine Quick Nano Browser}{Nano Browser}. - - \section1 Web Notifications - - Qt WebEngine supports JavaScript \l{Web Notifications API}. - The application has to explicitly allow the feature by using - QWebEnginePage::Notifications or \l{WebEngineView::Feature} - {WebEngineView.Notifications}. - - Support for this feature was added in Qt 5.13.0. -*/ |