1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
|
// Copyright (C) 2017 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page qtwebengine-overview.html
\title Qt WebEngine Overview
The \QWE module provides a web browser engine that makes it easy to embed content from
the World Wide Web into your Qt application on platforms that do not have a native web engine.
\QWE provides C++ classes and QML types for rendering HTML, XHTML, and SVG documents,
styled using Cascading Style Sheets (CSS) and scripted with JavaScript. HTML documents can be
made fully editable by the user through the use of the \c{contenteditable} attribute on HTML
elements.
\section1 Qt WebEngine Architecture
\image qtwebengine-architecture.png
The functionality in \QWE is divided into the following modules:
\list
\li \l{Qt WebEngine Widgets Module} for creating widget-based web applications
\li \l{Qt WebEngine Module} for creating Qt Quick based web applications
\li \l{Qt WebEngine Core Module} for interacting with Chromium
\endlist
Page rendering and JavaScript execution are separated from the GUI process into the \QWE
Process. It is a library that must be shipped with the application if the Qt libraries are
bundled into the application.
\section2 Qt WebEngine Widgets Module
\image qtwebenginewidgets-model.png
A \e {web engine view} is the main widget component of the \QWE module. It can be used
in various applications to load web content. Within a view, a \e {web engine page} holds a main
frame that is responsible for web content, the \e history of navigated links, and \e actions.
The view and page are quite similar, as they provide a set of common functions.
All pages belong to a \e {web engine profile} that contains shared \e settings, \e scripts, and
\e cookies. Profiles can be used to isolate pages from each other. A typical use case is a
dedicated profile for a \e {private browsing} mode, where no information is permanently saved.
\note The \QWE Widgets module uses the \l{Qt Quick Scene Graph}{Qt Quick scene graph}
to compose the elements of a web page into one view. This means that the UI process
requires OpenGL ES 2.0 or OpenGL 2.0 for its rendering.
\section2 Qt WebEngine Module
\image qtwebengine-model.png
The \QWE QML implementation contains the same elements as the \QWE Widgets
implementation, except that there is no separately accessible web engine page.
The supported page functionality is integrated into the web engine view.
\section2 Qt WebEngine Core Module
The \QWE core is based on the \l {Chromium Project}. Chromium provides its own network
and painting engines and is developed tightly together with its dependent modules.
\note \QWE is based on Chromium, but does not contain or use any services
or add-ons that might be part of the Chrome browser that is built and delivered by Google.
You can find more detailed information about the differences between Chromium and Chrome in this
\l{https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md}{overview}
that is part of the documentation in the \l {Chromium Project} upstream source tree.
This version of \QWE is based on Chromium version 94.0.4606, with additional security
fixes from newer versions. The Chromium version can also be read at runtime using the
\l qWebEngineChromiumVersion() method, and \l qWebEngineChromiumSecurityPatchVersion()
to read the current patch level. You can also find the versions in the QtWebEngine
sources in the CHROMIUM_VERSION file.
\section2 Qt WebEngine Process
The \QWE Process is a separate executable that is used to render web pages and
execute JavaScript. This mitigates security issues and isolates crashes caused by specific
content.
\section1 Embedding Web Content into Widget Based Applications
Use the QWebEngineView class to display web pages in the simplest way. Because it is a widget,
you can embed QWebEngineView into your forms and use its convenience functions to download and
display web sites.
\code
QWebEngineView *view = new QWebEngineView(parent);
view->load(QUrl("http://www.qt.io/"));
view->show();
\endcode
An instance of QWebEngineView has one QWebEnginePage. QWebEnginePage can have a
QWebEngineHistory that provides access to the page's navigation history and several QAction
objects that apply actions on the web page. In addition, a QWebEnginePage has the ability to
run JavaScript code in the context of the page's main frame and to enable customization of
handlers for specific events like showing custom authentication dialogs.
Each QWebEnginePage belongs to a QWebEngineProfile that can have a QWebEngineSettings
for specifying page settings, a QWebEngineScriptCollection for running scripts on the page, and
a QWebEngineCookieStore for accessing the HTTP cookies of Chromium. A QWebEnginePage can also
directly point to a script collection.
For a widget based application, the web engine is automatically initialized, unless it is
placed in a plugin. In that case, it must be initialized in the application main source file
by using \l QtWebEngineQuick::initialize, as illustrated by the following code snippet:
\code
int main(int argc, char **argv)
{
QtWebEngineQuick::initialize();
QApplication app(argc, argv);
QMainWindow window;
window.show();
return app.exec();
}
\endcode
\section1 Embedding Web Content into Qt Quick Applications
The WebEngineView QML type allows Qt Quick applications to render regions of dynamic web
content. A \e{WebEngineView} type may share the screen with other QML types or encompass the
full screen as specified within the Qt Quick application.
To make sure that OpenGL context can be shared between the GUI and render processes, the web
engine must be initialized by using \l QtWebEngineQuick::initialize in the application main source
file, as illustrated by the following code snippet:
\code
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
QtWebEngineQuick::initialize();
QQmlApplicationEngine engine;
engine.load(QUrl("qrc:/main.qml"));
return app.exec();
}
\endcode
An application can load pages into the WebEngineView, using either an URL or HTML string, and
navigate within session history. By default, links to different pages load within the same
WebEngineView object, but web sites may request them to be opened as a new tab, window, or
dialog.
The following sample QML application loads a web page using the \l{WebEngineView::}{url}
property:
\quotefromfile webenginequick/minimal/main.qml
\skipto import
\printuntil /^\}/
\section1 Script Injection
\QWE does not allow direct access to the document object model (DOM) of a page.
However, the DOM can be inspected and adapted by injecting scripts.
The DOM of a page is constructed when the document is ready, typically
when the page is completely loaded. Therefore, executing scripts as soon as a document is
created is not suitable for DOM operations, where one has to wait until the DOM is ready.
In addition, an injected script shares the same \e world as the other scripts executed on the
page, which might lead to conflicts. To avoid this, the QWebEngineScript class and the
WebEngineScript QML type provide implementations of the Chromium API for
\e{Content Script Extensions}. They specify the
script to run, the injection point, and the world where the script is run. This enables
accessing the DOM to manipulate it within a world.
Since Qt 5.8, \QWE supports augmenting a script by using the
following \l{Metadata Block}{Greasemonkey-like attributes}:
\list
\li \c {@exclude <regexp>}
\li \c {@include <regexp>}
\li \c {@match <regexp>}
\li \c {@name <free text>}
\li \c {@run-at [document-start|document-end|document-idle]}
\endlist
The attributes determine if and when a \l {User Scripts}{user script} is
run. They must be placed immediately in the beginning of the script, inside
a \c ==UserScript== comment:
\code
// ==UserScript==
// @include http://*.qt.io/*
// @exclude http://wiki.qt.io/*
// ==/UserScript==
window.alert("Page is from qt.io, but not wiki.qt.io");
\endcode
If your WebEngine application is built using the Qt Quick Compiler, and the application ships
JavaScript files inside .qrc resources, consider reading the section
\l{JavaScript Files in Qt Resource Files}.
\section1 Managing Certificates
\QWE uses its own network stack, and therefore QSslConfiguration is not used to
open SSL connections. Instead, \QWE uses the root CA certificates from the operating
system to validate the peer's certificate.
The \l{WebEngineCertificateError::error} and \l{QWebEngineCertificateError::Type} enumerations
provide information about the types of certificate errors that might occur. The errors can be
handled by using the WebEngineView::certificateError QML method or by connecting to the
QWebEnginePage::certificateError signal.
\section1 Proxy Support
\QWE uses the proxy settings from \l{Qt Network}, and forwards them to Chromium's
networking stack. If QNetworkProxy::applicationProxy is set, it will also be used for \QWE.
If QNetworkProxyFactory::usesSystemConfiguration() is enabled, the proxy settings
are automatically retrieved from the system. Settings from an installed QNetworkProxyFactory
will be ignored, though.
In case QNetworkProxy::user() and QNetworkProxy::password() are set, these credentials
will be automatically used for proxy authentication. It is up to the user to provide valid
credentials, since there is no error handling callback.
If no credentials are set with QNetworkProxy, but the proxy requires authentication,
QWebEnginePage::proxyAuthenticationRequired is emitted.
For Qt Quick, a dialog is shown.
Not all properties of QNetworkProxy are supported by \QWE. That is,
QNetworkProxy::type(), QNetworkProxy::hostName() and QNetworkProxy::port() are taken into
account. All other proxy settings such as QNetworkProxy::rawHeader() are ignored.
\section1 High DPI Support
To support High DPI devices, it is recommended that the application attribute
Qt::AA_EnableHighDpiScaling is set to enable automatic scaling based on the
pixel density of the monitor. In \QWE applications, the scaling
affects the default zooming factor and scrollbar size.
For example:
\code
int main(int argc, char *argv[])
{
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QApplication app(argc, argv);
// ...
}
\endcode
\QWE bundles images for normal and high-dpi resolutions into
\e qtwebengine_resources_100p.pak and \e qtwebengine_resources_200p.pak
files. Depending on the target resolutions, one or both of these files need
to be deployed.
For more information, see \l{High DPI}.
\section1 Using WebEngine Core
\QWE Core provides an API shared by \QWE and \QWE Widgets for handling
URL requests issued for the networking stack of Chromium and for accessing its HTTP cookies.
Implementing the QWebEngineUrlRequestInterceptor interface and installing the interceptor on a
profile enables intercepting, blocking, and modifying URL requests (QWebEngineUrlRequestInfo)
before they reach the networking stack of Chromium.
A QWebEngineUrlSchemeHandler can be registered for a profile to add support for custom URL
schemes. Requests for the scheme are then issued to QWebEngineUrlSchemeHandler::requestStarted()
as QWebEngineUrlRequestJob objects.
The QWebEngineCookieStore class provides functions for accessing HTTP cookies of Chromium.
The functions can be used to synchronize cookies with QNetworkAccessManager, as well as to set,
delete, and intercept cookies during navigation.
\section1 Platform Notes
\QWE currently supports only Windows, Linux, and \macos. Due to Chromium build
requirements it also often requires a newer compiler than the rest of Qt. See
\l{Qt WebEngine Platform Notes} for further details.
\section1 Related Modules
\QWE supersedes the \l{http://doc.qt.io/archives/qt-5.3/qtwebkit-index.html}{Qt WebKit}
module, which is based on the
WebKit project, but has not been actively synchronized with the upstream WebKit code since
Qt 5.2 and has been deprecated in Qt 5.5. For tips on how to change a Qt \WebKit widgets
application to use \QWE widgets, see \l{Porting from Qt WebKit to Qt WebEngine}.
The \l{Qt WebView} module allows to use a native web browser on platforms where one is
available.
The \l{Qt WebChannel} module can be used to create a bi-directional communication channel
between QObject objects on the C++ side and JavaScript on the QML side.
*/
|
