| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This also allows the software code path to be enabled:
- Programmatically by setting this dynamic property on the QCoreApplication:
"QQuickWebEngineView_DisableHardwareAcceleration"
- Through the Chromium command line switch "--disable-delegated-renderer"
for quick development use cases.
Change-Id: I32136d880444e0a24f042c7c4862950b7ed0c910
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: Ideefbf272d0affa3f53c5795b779f1bfc9c9bf70
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
| |
Change-Id: If97c7b50efc7bf01095cb4a7138208ab2c6b2e9b
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
This is just the basic core part and widgets plumbing and default
implementations of the virtual functions in QWebEnginePage.
QtQuick implementation is still yet to be done
Change-Id: I7cf8d6e5ec0bf747d45e9914db57bd0e4ef95b7f
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes loadProgress in both widget and quick webengineviews.
However, the progress will not change until we get an upstream change
in Chromium where the content LoadProgressChanged API is exposed to all
ports, not just Android. The upstream change is
https://src.chromium.org/viewvc/chrome?revision=221010&view=revision
Once we get that change, you'll see the widget example browser start to
paint a blue progress rectangle in the background of the URL bar. Also,
a progress bar was added to the quicknanobrowser, but it will be stuck
at 0 for now.
Change-Id: Icbaa01b86c013e0052b3abb7672c38e57128f44a
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a favicon API modelled after the WebKit2 QQuickWebView API, but
using an http(s) URL instead of a custom protocol, because there's no
icondatabase yet.
The icon URL lingers even when a new load is committed, until the load
finishes. It might be more prudent to clear the icon when committing a
new load, but I opted to let the app take care of that detail if
desired. Many browsers show a spinner instead of the favicon while
loading, for example.
There's no widget API implementation for favicons yet, because that API
only makes sense if we have a full-fledged icon database (case in
point: QWebEngineSettings::iconForUrl()).
Change-Id: I1e7b85104c80de2ae46a5fe9a273104d43a5c71f
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
| |
This is not needed anymore since the ownership changed
Change-Id: I7bfbb51c79a0d48ca8197a9b3a5d18986ee40e36
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the necessary changes to handle
WebContentsDelegateQt::AddNewContents and funnel the callback
through createWindow in QWebEnginePage and QWebEngineView.
- Expose the AddNewContents callback through WebContentsAdapterClient
- Allow creating a WebContentsAdapter attached only on the Chromium side,
leaving the choice to QWebEnginePage to either adopt it and call
WebContentsAdapter::initialize to attach itself as the client, or
destroy it if the application isn't handling the call.
- Delay the InitAsChild handling in RenderWidgetHostViewQt when
it is called before an adapter client has been attached.
- Since WebContentsAdapterClient::CreateRenderWidgetHostViewQtDelegate
is only a factory method, not creating any link with the callee client,
allow using the creating window's adapter client to create the RWHVQtDelegate.
This allows an unparented delegate to be created instead of needing to
add numerous null-checks in RWHVQt.
Use content::WebContents::CreateParams::context for this purpose,
which can be used both when creating a WebContents ourselves and when
a new window's WebContents is created for us.
Change-Id: I032262e867931dc40a7c2eca0c993027a555f56e
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Flatten the ownership tree by removing WebContentsDelegateQt from the
ownership chain of the content::WebContents.
This also let WebContentsAdapter do the needed initialization work.
Change-Id: Ie652bbcad54799b66d28a4a33e627f667b1c0d28
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the common GURL->QUrl and string16->QString conversions
into a common header and use those functions throughout the code.
Move the qStringToStringType into the same header and rename it
to a name consistent with the others.
This also cleans up shared_globals.h by moving content:: forward
declarations in the cpp, where they are used.
Change-Id: I19527ea7de1f6047aae8b44c97eb4d7c3e5a0e54
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add WebContentsObserver as a base class of WebContentsDelegateQt
to be able to get more information about the WebContents (loading
state etc.).
Also implements load finished with a success value to be able to
show when a load has failed.
Change-Id: Ic2ad698d180b395cf3d9fb6cd49b12c9cb4fb493
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step to making proper Qt Modules out of QtWebEngine.
The Widgets integration becomes a proper C++ Qt Module while we make
the QtQuick side a QML plugin for now (could probably be promoted if
the need arises).
Code-wise, this means the introduction of a WebContentsAdapterClient
interface that is subclassed by the private implementation of our API
classes for delegation of things that are UI specific. Functionality
from WebContents and the like is exposed via the WebContentsAdapter.
Change-Id: I4ca3395b9fe8502a24e36002cfd5af44067bb6e8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Implement recently added pure virtual members:
BrowserContextQt::GetPath() const
BrowserContextQt::RequestMIDISysExPermission(...)
- Remove obsolete function GetSpeechRecognitionPreferences.
- Rename usage of GetActiveURL() to GetVisibleURL().
- Update namespace for usage of type WebPluginGeometry.
- Adjust parameters of RenderWidgetHostViewQt::TextInputChanged.
- Rename RenderWidgetHostViewQt::RenderViewGone to RenderProcessGone
- set_http_server_properties now takes a scoped_ptr.
- Rename WebDropData to content::DropData.
- Rename WebMenuItem to content::MenuItem.
- webkit/support/webkit_support.gyp has been moved to
webkit/webkit_resources.gyp.
Change-Id: I6d5d281b797a8f6197ecb53a08798bd1f6845754
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Using the NotificationObserver mechanism for this purpose
seams to be a bit of overkill so remove the inheritance from
WebContentsDelegateQt. We can re-add it later if we find useful
notifications.
Change-Id: I4dff59f66893cd36ed8c0700fa492a3eeb99f87b
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Mostly removing duplicated code so far.
|
|
|
|
| |
Seems more future-proof to only depend on Gui as much as possible.
|
| |
|
|
|
|
|
|
|
| |
process uses the same code as lib and decides at runtime which
code to run. Fix the debug build by making sure that all infrastructure
code is available in both process and lib by building common code
not shared directly through chromium sources in a separate static lib.
|
|
|