| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This value is only used internally by Chromium and risks being removed
at anytime, for which we would then have to maintain a downstream
implementation.
Chromium also only supports frame values, while a complete support of
the interface would require also supporting this xPath to point to
individual document element by affecting the value of "this", the same
way that QWebElement::evaluateJavaScript allowed in QtWebKit.
Change-Id: Id0cb1b8e3bdf9a6db0ca786fb5eb46ffd726d165
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
|
|
|
|
|
|
|
|
| |
The property is still not properly implemented and we'll make it
first go through the experimental tryout like other APIs we add.
Change-Id: I6eb99fcebb7ca1fc33338d786585cfe7fbc0afd4
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
Remove unreachableUrl support from WebContentsAdapter::setContent,
because this argument behaves exactly the same as baseUrl.
Change-Id: I36f92b99b7045c6d3b831481bb04d51a0e05772f
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
| |
I dropped hovered title support from the QtWebKit API,
it seems we don't need that logic.
Change-Id: I5617c295344512a35aa526a6f1307f0b21f866d6
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
| |
Change-Id: I18059c2894893d28c03dc790037bdd3ff28cfd07
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an assertion for QML code like:
WebEngineView {
...
MouseArea {
...
}
}
Change-Id: I7a9bfb801c81ea53c1cc830b44fe224a0b78db2d
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I initially misintepreted the meaning of the enum, assuming that it
meant that the window should possibly be blocked. The user_gesture
parameter in WebContentsDelegate::AddNewContents is actually doing
this, while the popup disposition means that JavaScript requested
the window to be opened without one of the standard decoration (i.e.
status bar, menu bar, tool bar, etc.).
Update the QtQuick API to reflect this, renaming the "isPopup"
parameter to a more familiar "isUserInitiated".
The popup disposition is named "dialog" to match the previous
QWebPage::WebModalDialog enum.
Change-Id: Ib0c4bc53671fcf0dd9499aa1be2bbc8c494ba49e
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
|
|
|
|
|
|
|
|
| |
Translates the internally used LogSeverity values to
enums defined by the QtWebEngine integration layer.
Change-Id: I7da0983d4fb5c199e1a2436b5899a43cf6698784
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
| |
We now only have a QQuickItem subclass and this isn't needed anymore.
Change-Id: I3a10943e54f52d1554dc76ccc1841aaacd5171e2
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
| |
Now that the widgets view is also using the delegated renderer,
there are no supported configuration that use the BackingStore
rendering path, itself on the way of deprecation in Chromium.
Change-Id: I4ab889f6a7c65e8447c259faf2c7a98b88c1acf5
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts parts of commit 9c198939be1ef064d1a2430a4b9991f2fe16f359.
This does keeps the popup fixes and removes support for
QWebEnginePage::setViewportSize and QWebEnginePage::render until
we can evaluate the needs vs the cost of such feature.
Change-Id: I1b55b751d463717b1462393ea8cd353422f8fdbb
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
| |
With this fix the quick history list is updated like in the widget API.
Change-Id: I19127a0055a3f1ab8a04da63d847249f6c4c23d9
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is used by popups for select elements and date pickers among
other things. We can keep using the same RenderWidgetHostViewQtDelegate
implementations for that purpose, and query QPA to decide if they
should be wrapped into their own QQuickWindow.
Longer term, we might want to optionally delegate that functionality
to QML.
Change-Id: I88540ca32a9a707d380dfbf486b7f7806b5b65ff
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mainly remove the use of the LoadingStateChanged callback, which
is tied to DidStartLoading and DidStopLoading.
Those signals are handled from the browser process side, also wrapping
the time where the render process is initialized. We can't rely on
those signals for loadStarted, but afterward rely on the Blink loader
for loadFinished. We must use the same source for both.
Instead only rely on Blink callbacks ultimately related to network
events. This gives us a behavior closer to QtWebKit.
The major compromise that this forces us to to accept is that
loadStarted is now triggered asynchronously. This will basically break
anything expecting loadStarted to be emitted synchronously from the
load method.
This also adjust autotests to get a few more passing.
Initial-patch-by: Pierre Rossi <pierre.rossi@digia.com>
Change-Id: Ib6c0170df891d1b7f8ed4dc1d483985523e267dc
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
| |
Add QQuickWebEngineHistory and list models providing API for the quick's
navigationHistory.
Change-Id: Ia86c94b120cc5d0b4757fc62386fc7a0dcb3e341
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The forceActiveFocus() doesn't work in the QML tests.
We need to call forceActiveFocus() in RenderWidgetHostViewQtDelegateQuick
instead of the one in WebEngineView. To make this work, I replaced RWHV
with QQuickWebEngineView in the focus chain.
This is necessary in order to extend tst_loadUrl QML test with
urlProperty test case.
Change-Id: Ifba0c824a7ce9f00d328110233402d3563f967aa
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
| |
Rename QQuickWebEngineView.loadingStateChanged signal name to
QQuickWebEngineView.loadingChanged.
Change-Id: I0e01034f7b2eea57f5211ff0d8258d9f27d278f0
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Much like the widgets version.
This should be helpful to start testing QWebChannel integration.
Includes a very basic autotest that checks both approaches (with or
without callback) through the view's title property.
Change-Id: Id9c3e3736f36d53cecf1dd52e8811c4b921dcf08
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
| |
Cleanup version ifdefs and v8-private dependencies.
Change-Id: Iac393c06dfba02499e60d713d9f4d04ef0c9e617
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the code and API in a few ways:
- Expose a more discoverable "request" argument in the signal.
- Use the request as the carrier of the backend WebContentsAdapter
and get rid of our handle.
- Put the adoption method (renamed to openIn) on the request object
and keep the view API clean of a context-specific adoptHandle method.
- Use an enum instead of strings for the new view destination.
- Do not let JavaScript own the request object since it won't be
necessary until we want to support asynchronous view attachment.
We can create the request object on the heap and let the JavaScript
engine own the object once we want to support it.
- Move the request class to its own header.
- Replace tabs.currentView by currentWebView in the quicknanobrowser
qml code since we now need this property on the root object anyway.
Change-Id: I40d7d15255f516ead9f3e414dd587bf345e6ca4b
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
| |
Task-number: QTBUG-36472
Change-Id: I60267d6b9e2e99b20ddf604a0d6b0d8f2c8f1b27
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
Implement unreachableUrl support for WebContentsAdapter::setContent
and add loadProgressAfterLoadHtml QML test case.
Change-Id: I2d0d7834cbbf8f508de4fa9cb72240f2ac6ebf83
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
QQuickWebEngineViewPrivate needs a destructor to work right with
WebContentsAdapter.
Change-Id: I3df1b452eeaf3a7516eace9268884ff6d1211e44
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a property isFullScreen and a signal
fullScreenRequested to QQuickWebEngineViewExperimental.
The signal fullScreenRequested is emitted when some web content
requests fullscreen through the javascript API.
The property isFullScreen is supposed to be set
programmatically when the view is being shown fullscreen.
This information is then available to the WebContentsDelegateQt
when checking if the fullscreen request has been accepted.
Change-Id: I04cbb45f263a188d26cc87d70ac53b0fbab63936
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Chromium calls RenderViewHostDelegate::TakeFocus when the
last focusable item within the page was reached.
We then have to move the focus on to the next/previous
QQuickItem.
Change-Id: Id0128053602ff1220c1bced1b218050b66fef659
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support reparenting, we make the compositing surface independent of
the window by using gfx::TEXTURE_TRANSPORT. We also need to be able to
keep frame data across window changes so we can reconstruct the QSGNode
tree in a new context, so extract that data into DelegatedFrameNodeData
class. Any context-specific data is still stored in DelegatedFrameNode.
Also hook up window changes to WebContents::WasShown/Hidden for Quick.
Remove checking of Qt isVisible state, this mechanism is used to sync
Chromium with Qt, not the other way around. WasShown/Hidden is
orthogonal to Show/Hide, and can use different triggers. However for
Widgets it probably makes sense to hook both up to widget visibility.
Change-Id: I1ef4b50cd61b8e54b791e03f0b41929c42fec8bf
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
| |
And unskip the corresponding autotest.
Change-Id: Ida2dcee38b261b2ba4ad0c5c016f5510ed1590a4
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should provide us with an initial empty document, which our
imported autotests tend to assume all over the place.
Initialization of the adapter is moved further down in
QQuickWebEngineView's constructor so that the value of
q_ptr is set and valid by the time we end up in
WebContentsViewQt::CreateViewForWidget.
Change-Id: I45d8d61e65caa3a690461b6da44adea9f8981e7e
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should not include chromium headers outside of core since
they might depend on defines or other build options only set in
the gyp/ninja environment.
This patch removes the need to include net/base/net_errors.h
in the API implementation of the QQuickWebEngineView and also
removes the chromium source directory from the global include
path. This prevents including chromium headers outside of core
by mistake and also makes it possible to load the project in
QtCreator without disabling indexing.
Change-Id: Icd13b6caa52509ef2a1b6b44eaffb34d8ae4addf
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: I56c78aa7e60194888123d372c6dbbb60624856c5
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
| |
Change-Id: I6195c49f1647c78b16d9d47770ab37ba998a61a5
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Refactor JavaScriptDialogManagerQt to support a Qt Quick dialogs
friendly approach.
Qt Quick dialogs are still missing a prompt, so we use a "handmade"
one. This should be solved before 5.3 though.
Change-Id: I965df66837b2e81d6e4618a8da1167a37661c26e
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with the context Menus for QtQuick.
Add default UI delegates as a subproject. We allow ourselves to use
Qt Quick Controls there for in order to get a nice "out of the box"
experience for things like context menus, dialogs, etc while leaving
the door open for system embedders to override this.
Opting out of the deployment of these QML files is still very primitive
but can be done by passing WEBENGINE_CONFIG+=no_ui_delegates at qmake
time.
Customization of context menus could be done via a qml component, which
is probably best kept in experimental for now while we address its
shortcomings.
Change-Id: I0705b20d5ddd3bb010f9371b65a181c6b02a03e1
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
| |
It contains information about a requested load of a web page.
Change-Id: Ie45706adb51ee5bce98e7af01252d9a8389db57d
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements adoptNewWindow for QQuickWebEngineView.
The API is only intended to be used through QML to avoid delegating
the QQuickWebEngineViewHandle ownership through a signal parameter.
Another limitation of the implementation is currently to fail the
handle adoption unless it is done synchronously within the
adoptNewWindow call. To support this we would need to delay the call
to WebContentsAdapter::initialize which will leave the adapter
without a client when returning to the event loop and would require
putting null checks everywhere it is used.
So I would prefer to keep the API limited and avoid potential crashes.
If we want to support asynchronous Loader elements or QML files
fetched from the network in the future, the API should be able to
scale to the task once we've adjusted the implementation.
This also adds basic tabs support in the quicknanobrowser example.
The url property is now set imperatively to avoid overwriting the
adopted WebContentsAdapter's loading URL.
Change-Id: Iba5c5dc3ffa21045f356be131ca15c01b9aee7c8
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: I5130a10d56cc7c25da0eabf51c3657ef58cebaa7
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This specifies a devicePixelRatio to be used by web content instead of
the QScreen::devicePixelRatio(). This is necessary on non-iOS mobile
devices to remain compatible with the mobile web which assumes
devicePixelRatio is computed as the ratio of actual dpi to 160 dpi.
Non-iOS mobile platforms may use different criteria to determine the
QScreen::devicePixelRatio(), depending on the history of the platform,
or simply leave it at 1.0.
For QNX, this setting gets a reasonable default value so developers
don't have to regularly use this experimental API.
These changes were inspired by the Android Chromium port which uses a
GetDpiScale() to accomplish the same in
content/browser/android/content_view_core_impl.cc.
Change-Id: I1bc8878a47dabcdb6986c4fe5c8c4ac230ae2514
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
This only move files without adjusting any paths.
This moves:
- lib/quick -> src/webengine/api (API files)
lib/quick -> src/webengine (other files)
This contains the main QtWebEngine module library since
<ec7b2ee70a8b2db7fb87f50671a001ddd54697b0>.
- lib/widgets -> src/webenginewidgets
Also rename this directory to match its module name and rename Api to api.
- lib -> src/core
- process -> src/process
- resources -> src/core/resources
- tools/* -> tools/scripts/
The build directory is spread as follow:
- build/build.pro -> src/core/gyp_run.pro
- build/qmake_extras/* -> src/core/ (for the host and target .pro files)
- build/qmake -> tools/qmake
- Build related scripts -> tools/buildscripts
Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|