This test fails, because we get two loadProgress signals with
the 100 value if the page load is successful.

Change-Id: Idbd68c28ba81f8ff0a5b1d98aece82e7a940f1b9
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

This adds API for overriding some certificate errors. Once overridden
any identical error for the same hostname and certificate will use
the same override.

Similar API for QtWebEngine QML should be added in a later patch.

Change-Id: I144147b86d9b592e3f87346a1e48890acee0c670
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>

Adds one of the missing pieces of the QWebFrame and QWebView APIs.
Unlike the QtWebKit version this only fetches the favicon URL, and not
the icon. This is because we do not want to implement an icon database,
and that the icon would be loaded asynchronous anyway, bringing no
guarantee to be a valid icon/image yet.

Change-Id: I227311ae3676044da850e687b82bee752b5079c8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>

Change-Id: Ib2deac6099c37f1e112821fb3398586269e05f22
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

Headers were left intact to leave a trace of the evolution compared
to the QtWebKit API and to make it easier to work until we had a
basic subset of the API implemented.

With the upcoming release, this patch removes this convenience in the
aim of starting polishing the headers and the documentation for the
upcoming release.

Change-Id: Iae436b4ec041d771a7002575e122835802bc9f3e
Reviewed-by: Michael Bruning <michael.bruning@digia.com>

To match other modules example directory structures we should deploy our
examples in a directory matching the module name, webengine and
webenginewidgets in our case.

qmake uses the relative directory of each example up to the upper "examples"
directory to decide where they will be deployed when running the sources
install target.

Change-Id: I59ce7ff8a30f98fad20064c7eecf72b784f1d275
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>

This allows handling calls that would be signaled by QNetworkAccessManager
in QtWebKit.
This pulls QtNetwork as a dependency of the QtWebEngineWidgets module
to be able to use QAuthenticator, but isn't required otherwise.

Only the request URL is available in the case of HTTP authentication
(no access to HTTP request headers that the QNetworkReply would allow)
and only the proxy host name in the case case of proxy authentication.

This keeps the API synchronous the same way, as QtWebKit did, in
favor of source compatibility at the cost of requiring a modal
dialog, even though the implementation doesn't require it.

Change-Id: I9e021def38e6107c9e66d2de8f86bd0328d543df
Reviewed-by: Michael Bruning <michael.bruning@digia.com>

This makes the demo compile, but not link since
most of the methods aren't implemented yet.

Also disable downloads and printing since they require a bit
more work to instead use the page directly.

Change-Id: I59adfe07fda077c6909f70f12800a4cfa6a6dad2
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

Import the sources as-is, without adding it to the build, to allow
performing diffs later on the changes that were needed to port it
to use QtWebEngine and manage source compatibility issues.

Change-Id: Icf8a284881ce2153e9b5a1ba97dbe77096f1b88d
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

This follows the model used by the rest of Qt, potentially
avoiding binary compatibility issues.

The compromise is that we now depend on core-private, thus
forcing us to follow Qt's release cycle.

Change-Id: Ib2df51071fc35935ac99edf7b9c5562949cb43e2
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

Change-Id: I58d83f4f33728f92e4bf13b6be30b15528fdd033
Reviewed-by: Zeno Albisser <zeno.albisser@digia.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>

- Rename NativeViewQt to RenderWidgetHostViewQtDelegate to keep the
  context obvious.
- Use an interface to handle the parenting instead of the
  NativeViewContainerQt mechanism that was needed with the Shell.

Rename the class to WebEngineContext and keep it as a ref-counted member
of pages instead. Also:
- Change the user-agent product to QtWebEngine
- Don't pass actual command line arguments to Chromium anymore
- Allow attaching to the event loop through Before/AfterRun instead of blocking

This layers things properly to be able to implement the UI in the
example application instead of directly in shell_qt.cpp.

This is still using global variables to allow the Shell platform
code to do callbacks to the API classes. This should go away once
we properly implemented a WebContentsDelegate.

The current preliminary implementation uses the QQuickPaintedItem.

The RasterWindow is being replaced by an abstract NativeViewQt
class, which can be instantiated as QWidgetNativeView or QQuickNativeView.
The NativeViewContainerQt builds a wrapper around an instance of these classes
and serves as a common api towards chromium.

Due to the current design where the view is being created by the shell,
we introduce a browser_window.qml which provides a very basic browser UI.
The content is then being injected into an item within that browser window.

Just executing the example the "regular" way will launch the Widgets example.
To launch the QtQuick2 example, the environment variable QQUICKWEBENGINE must
be defined.