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>

Keep the size in the page itself, and ask the optionally attached
QWebEngineView only for the rect position.
When the view size change, call setViewportSize on the page like
QtWebKit does.

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

We also need to update the WebContentsAdapter pointer in
QWebEngineHistoryPrivate.

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

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

A few changes to the API:
- Return the success result asynchronously.
- FindWrapsAroundDocument and HighlightAllOccurrences are enabled by
  defaults and cannot be disabled.
- Found text isn't updating the selection on the page like QtWebKit
  did, but triggers a separate state not available. A find count and
  current index could be exposed, but isn't in this case to keep the
  API delta lower.

This also adds the possibility to pass bool results through the
CallbackDirectory and add a new tst_QWebEnginePage::findTextResult
test since the old test relied on the selection to be updated when
the searched text is found.

Change-Id: I8189b5aea8d832df183c6c1ae03e3f08198a9c45
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

Change-Id: Idebde8da0befbea7ccc5942de1e09fcc61ce16d4
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

With the upcoming addition of a new type of callback result, this
patch allows storing multiple callback types in the same QHash instead
or requiring a different hash table just to please the type system.

This does so by managing the ref-counted callback pointers directly
instead of relying on a templated QExplicitlySharedDataPointer that
requires a different type for each different callback pointer type.

The ref-counting, construction and destruction is managed through
a run-time type enum.

Change-Id: I90ab2e1efc0c9703fc5b6ef57b38204ac8eea828
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

This tries to get the order of declaration to be consistent.
It also follows the order used by Chromium in some places
where the routing_id usually comes first, then the request_id
and then the result of the asynchronous request.

Change-Id: I88e164dee67e1631161a222f7dd7a4679c3d3acd
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

Change-Id: I87c18edb89658433d6dc3487ab92d2ff7bd6c986
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>

Unlike load, the value passed to setUrl should be returned by url
until the url is updated by the page (load finished or url changed).

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

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

Update tests to check that we can keep the same functionality by
querying document.baseURI through runJavaScript instead of implementing
QWebEnginePage::baseUrl.

This also removes QWebEnginePage::baseUrl from the header.

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

Break up the delegate implementation into two distinct subclasses.
The first one offers a way for the WebPage to tap into the
RenderWidgetHostView directly, while a different implementation
that is backed by a top-level widget can be used to show WebUI
popups on screen.

This has the benefit of not having a child widget in the webview
among other things. It also fixes our popups and allows them to fall
outside the window frame.

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

And unskip the corresponding autotest.

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

The current implementation offers no way to cancel async requests.
This means that normal applications could easily allow callbacks
to dereference a destroyed object unless they use a smart pointer
within the callback function object.

This patch will empty the pending callback list by calling each of
them with an empty value. This will at least allow applications to
cover the cases where the page is expected to have a shorter or equal
lifetime than objects referenced in the callback.

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

Those methods are now made asynchronous and need to be given a
callback to handle the result.

Update the code in the browser and fancybrowser examples using
std::bind when using C++11 or tr1::bind with C++03 (which should be
available with compilers on platforms that we support).

Add a (currently failing) earlyToHtml test to make sure that an empty
page doesn't crash because of a possibly incomplete attachment of
the QtRenderViewObserver.

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

This prepares the way for other API made async like toHtml and
toPlainText.

Use a callback class with an implicit templated constructor to carry
the functor across the API boundary and avoid the intermediate helper
method as the ABI that we have to maintain.

Also pass the callback result through WebContentsAdapterClient using
a bookkeeping ID instead of transferring the callback to
WebContentsAdapter. This will allow other calls, which might not
already allow passing a callback functor, to use a consisten way
of carrying back the result to the top API layer.

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

Load a generated data: URL to carry the data.

This is not as efficient as it could be but the behavior matches and
this should be fine for now.

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

This fixes the crash in tst_QWebEngineView::reusePage.
Also add a test to check the case where show() would react incorrectly.

Change-Id: I40247c7c225d74b26675b6a7fa5ff1f06d3bb3e6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.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>

Introduce a new version of chooseFiles in QWebEnginePage.
The existing API in WebKit1 seemed a bit dusty in any case (multiple
only supported via extensions).

Changes are:
  * oldFile becomes oldFiles, so that we could at a later stage expose
    the already selected files in the "multiple" case.
  * a type is introduced, for now limited to multiple selection, but
    over time, we might consider additions such as directory upload.

Change-Id: I14cfea64ce95e892a0a1877c8cb914c5a421409f
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 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
  <ec7b2ee7

>.
- 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>

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

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>

This experiment served its purpose and is now more often broken
than useful.

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

RenderWidgetHostViewQtDelegate acts as a bidirectional interface to
avoid exporting Chromium symbols outside of the core dynamic library.

The problem is that, other than this, from the top layer point of
view, its responsibilities are the same as RenderWidgetHostViewQt,
and it would be better not to split its logic without properly
defined responsibilities.

Using it as a base class and interfacing through its protected
methods is also cumbersome and make the destination of calls on the
upper layer difficult to discern.

Use instead a dual pure interface mechanism like WebContentsAdapter
and pass the callback client interface directly in
WebContentsAdapterClient::CreateRenderWidgetHostViewQtDelegate.
This allows RenderWidgetHostViewQtDelegate to be solely what it
should be, an interface.

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

We can't have QWebFrame::evaluateJavascript in its old form for
several reasons, the first of which being that we don't have a
QWebEngineFrame class anymore. This is worked around by adding
an optional QString parameter with the frame's XPath.

Another issue is that the WebKit1 API was synchronous, and this would
not play nicely with the very asynchronous nature of chromium we're
now sitting on top of. In order to make this obvious when porting, we
rename it to runJavaScript which doesn't return any result.

This also introduces a template member function overload that will
accept function pointers, functors and lambdas,much like Qt5's new
signal/slot syntax, in order to get the result of the javascript
evaluation back.

Change-Id: I64e15a6f5a168936c52a4da2cef6285dfd16e0d5
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

While we're at it, QWebEnginePage::createWindow is non const,
we could probably use a non const d-ptr in there.

Change-Id: If5ad43dcb5d13454c87b7dc84d69b976b1b5e334
Reviewed-by: Andras Becsi <andras.becsi@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 is essentially the widgets part, with some tricks to get it to
honor the widget's context menu policy.
It enables c++11 for the widgets library for the convenience of using lambdas,
which admitedly we could do without, but seems reasonable considering our timeline
and the fact that we build chromium that way.

Change-Id: I6a632a78d2aa48fb0dfecfe491e92651d12407db
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>

Change-Id: I7ef26e4a2e6c9eb228bcf5542ad272b998f8c6a3
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>

This value won't change and this will force us to avoid
spreading runtime checks.

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

This should enable namespaced builds of Qt and QtWebEngine.
Change-Id: I4c9d506d864b42a346026b980dcf3777b9680957
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.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>