-added \since and added commands such as \readonly
-converted enum values to use \value
-edited language and other minor issues.
-only the main Qt WebEngine, the widget docs will be edited
 later.

Change-Id: Ifbb76a6472b5efede15daebc78d605b8b449d957
Task-number: QTBUG-40757
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>

Change-Id: Idbe0eafb51d77cc00e3a93179b81770724d5bfaa
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Tuukka Turunen <tuukka.turunen@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>

Hide QObject's d_ptr member and use the macros when accessing
the private class. This patch also adds missing qt namespace
macros to the implementation.

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

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

A few changes are necessary to allow fetching textures provided by
the render processes through IPC and bound to their respective GL
context in the GPU process and use them in the QtQuick scene graph.

- Remove the plain color test textures.
- Allow setting the QtQuick QOpenGLContext's handle as the share
  context for all context set as shared in the Chromium GPU process.
  We do this by letting the GpuChannelManager ask us for a
  ShareGroup instance responsible for returning a sharing GL context
  handle.
- Fetch texture IDs from the MailboxManager used by the GPU process
  using the Mailbox given to us in the DelegatedFrameData.
  This is the same mechanism used by Chromium to share textures
  between "client" GL contexts.
- Keep the QtQuick scene graph threads and Chromium in-process GPU
  thread separate. The complicated part of merging those two
  rendering pipelines on the same thread is that it would force Qt
  to also use only one thread for rendering. For the moment we will
  try to synchronize those threads together instead.
- Lock the Qt SG thread while waiting for resource sync points.
  Do so by posting a callback to the Chromium GPU thread and wait
  until the sync point of every resource has been retired by the
  producing contexts.
- Acknowledge the delegated from once QtQuick swapped the GL buffers
  instead of right after we added the frame to the scene graph.
  This fixes some issues where the textures for the previous frame
  would already be released as Chromium was producing the new frame.

There are still a few issues regarding synchronization that have to
be fixed, especially when Qt triggers the rendering of a new frame
while Chromium is starting to produce the next frame.

Note: To enable it we still need to pass the following command switches:
--enable-delegated-renderer --enable-threaded-compositing --in-process-gpu

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

To implement the Web Inspector we need a delegate to handle the http
server and devtools connections, a landing page, a ContentClient to
tell the devtools server where to find its frontend resources, those
frontend resources, and an API for embedders to turn on inspectability
in WebEngineViews.

The frontend resources are build by the chromium build and are copied
over as part of lib's build.

The landing page was taken directly from content_shell. This
should be replaced by either a new one for all QtWebEngine embedders or
by a mechanism for embedders to supply their own (or both).

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

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

This is needed to handle createWindow where a WebContentsAdapter will
be created to wrap the new WebContents and will passed up through the
API. If the application doesn't handle the callback, this will allow
managing the lifetime of the WebContents more easily.

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

This isn't needed since the ownership was removed from WebContentsDelegateQt.

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

Mark the remaining methods as not implemented to allow enabling most
of the dependent code in the demo browser and in API tests.
Add two new tests to cover cases that might be problematic with the
index-based implementation.

This also renames WebContentsAdapter::navigateHistory to navigateToOffset
in order to avoid confusion with navigateToIndex.

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

The WebEngineContext member was declared after the WebContentsDelegateQt
in WebContentsAdapter. This means that the delegate was destroyed after
the context and would cause the crash.

Reorder the declaration and move the WebContentsDelegateQt also to the
private class to reduce future confusion.

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

Fix the gyp generator to allow including the moc file directly
in qwebcontentsview.cpp to be able to use Q_PRIVATE_SLOT
instead of having the private object deriving from QObject.

This also removes the use of MOCABLE_SOURCES whose entries were
added to 'sources' without moc being run on them first.

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.