| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the Chromium extensiuon system to Qt WebEngine.
Currently, it only exposes internal APIs to the internal
PDF viewer extension.
To load a PDF, simply navigate to it.
This feature can be configured via the webengine-extensions flag
and is turned on by default.
Needs patch in Chromium 71-based to build.
Adaptations to 71-based from 69-based include:
* Flag out update installation, add crx file dependency
* Move PostTask over to 71-based implementation
* Move extensions API providers to 71-based implementaion
* Don't use custom guest view and mime handler view delegates
* Adapt the URLRequestResourceBundleJob to match new interface
* Move extension system initialization to end of profile constructor
Change-Id: I4fa5149057291bb5847f048534c11820cd7ff58c
Fixes: QTBUG-50556
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
|
|
|
|
| |
Change-Id: Ib650113b05dfd4771240804f94e33c07aa317bf2
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/core/net/network_delegate_qt.cpp
src/core/profile_io_data_qt.cpp
src/core/web_engine_context.h
tests/auto/core/qwebengineurlrequestinterceptor/tst_qwebengineurlrequestinterceptor.cpp
Change-Id: Id98e3f52f548ceb5b68abd80aedd6ae59db72cc0
|
| |
| |
| |
| |
| | |
Change-Id: Ia86459503be86eb9b0d97affe94b7ce82d5e29f1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|\|
| |
| |
| | |
Change-Id: Idf2c89bebf5e09855d764808cac487bc4b76faaa
|
| |
| |
| |
| |
| |
| |
| | |
As the only platform macOS needs it initialized manually
Change-Id: I922aea7e9f19abac6c1b46822d48646d68784014
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Qt and Chromium keep track of the current GL context by using thread-local
variables, and naturally they are completely unaware of each other. As a result,
when a QOpenGLContext is made current, the previous gl::GLContext is not
released, and vice-versa. This is fine as long as each thread uses exclusively
either Qt or Chromium GL bindings, which is usually the case.
The only exception is when the GL driver is considered thread-unsafe
(QOpenGLContext::supportsThreadedOpenGL() is false), in which case we have to
run all GL operations, including Chromium's GPU service, on the UI thread. Now
the bindings are being mixed and both Qt and Chromium get quite confused
regarding the current state of the surface.
To get this to work we have to release the current QOpenGLContext before
executing any tasks from Chromium's GPU service and the gl::GLContext
afterwards. Since GPU service just posts tasks to the UI thread task runner,
we'll have to instrument the entire UI thread message pump.
Fixes: QTBUG-72017
Change-Id: Ibd72e3041d213217fd097dfb4272e49243e31e67
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|
Move to a separate file and cleanup the code.
Change-Id: I33d9536c7e40315b6bf271e33bdc3f838ab4b671
Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io>
|