| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We have settings and plugin setting now.
Change-Id: Id999c20a0e1d5d2b7272207827de8fd31377ba01
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
| |
|
|
|
|
|
| |
Avoid code duplication.
Change-Id: Icd270ff4e45112111b7eb9590e415947f63ce15b
Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows applications to receive unhandled key events from the page
by setting an event handler on the view's parent widget/item, like
it was possible with QtWebKit.
This is different in that events first have to asynchronously go
through the QtWebEngineProcess. If the WebEngine view has the
keyboard focus, the events will be consumed inconditionally by the
RenderWidgetHostViewQtDelegates, and a copy will be resent to the
view's parent if it wasn't consumed.
This sends it to the parent instead of the QWebEngineView directly
since those are only unhandled events, unlike with other widgets
where you can first intercept events. It is done that way also in
cases where the QWebEngineView would be be the focus widget directly
in the future, instead of the RWHV.
If applications want to intercept key events before they reach the
page, they need to use an event filter on the QWebEngineView's
children or globally on the application.
Change-Id: I3b48f5212d3f238a1c0497cec1db6ae3badbad26
Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
| |
If we consider the plugin scenario is unlikely and decide it's
unsupported for widgets, we can simplify our tests and examples
a bit on this front.
Change-Id: Idc96032c127b4ee74fb5c7b3d2cdfdf99c3a722e
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
This test runs without crash, but fails because the expected
interval of the load progress is too narrow.
For example, the progress values in my case: 0 -> 10 -> 100
Change-Id: I0fd13d6badf717fc27e8d4219f39190db0090692
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means that widgets application now need to setup the GL context
sharing as well. QWebEngineWidgets::initialize() must be called,
which has the same effect as QWebEngine::initialize().
The QtWebEngineWidgets now depends on the QtWebEngine module to make
this happen.
Since QOpenGLWidget is only available in Qt 5.3, this patch also
disables the webenginewidgets module completely when building using
Qt 5.2.
Change-Id: I0e99a779d1eb080f2ccf5a338ff0763ad64e6eba
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
Replace direct calls of toHtml and toPlainText to use a blocking
helper function that spins a QEventLoop to wait for the async result.
This should work fine for tests where the event loop is less polluted
by other events that could cause code reentrancy through stacked stacks.
Change-Id: Ic46a06a9abad782a39a620ceecdc51c3bbb6b5a1
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
Change-Id: If3617d86ea44f665a44a54b6ba57935b69220a9e
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
