/****************************************************************************
**
** Copyright (C) 2017 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/

/*!
    \page qtwebengine-debugging.html
    \title Qt WebEngine Debugging and Profiling

    \section1 Console Logging

    JavaScript executed inside \QWE can use the
    \l{Chrome console API} to log information to a console. The logging messages
    are forwarded to Qt's logging facilities inside a \c js
    \l{QLoggingCategory}{logging category}. However, only warning and fatal
    messages are printed by default. To change this, you either have to set custom
    rules for the \c js category, or provide custom message handlers
    by reimplementing \l{QWebEnginePage::javaScriptConsoleMessage()}, or
    connecting to \l{WebEngineView::javaScriptConsoleMessage()}.

    All messages can also be accessed through the \QWE developer
    tools.

    \section1 Qt WebEngine Developer Tools

    The \QWE module provides web developer tools that make it easy
    to inspect and debug layout and performance issues of any web content.

    The developer tools are accessed as a local web page using a Chromium or
    \QWE based browser, such as the Chrome browser.

    To activate the developer tools, start an application that uses \QWE
    with the command-line arguments:

    \badcode
    --remote-debugging-port=<port_number>
    \endcode

    Where \c <port_number> refers to a local network port. The web developer
    tools can then be accessed by launching a browser at the address
    \c http://localhost:<port_number>.

    Alternatively, the environment variable QTWEBENGINE_REMOTE_DEBUGGING
    can be set. It can be set as either just a port working similarly to
    \c --remote-debugging-port or given both a host address and a port. The
    latter can be used to control which network interface to export the
    interface on, so that you can access the developer tools from a remote
    device.

    For a detailed explanation of the capabilities of developer tools, see the
    \l {Chrome DevTools} page.

    \section1 Using Command-Line Arguments

    You can use the following command-line arguments while debugging to provide
    input for bug reports:

    \list
        \li \c {--disable-gpu} disables GPU hardware acceleration. This is
            useful when diagnosing OpenGL problems.
        \li \c {--disable-logging} disables console logging, which might be
            useful for debug builds.
        \li \c {--enable-logging --log-level=0} enables console logging and sets
            the logging level to 0, which means that messages of the severity
            \c info and above are recorded in the log. This is the default for
            debug builds. Other possible log levels are \c 1 for warnings, \c 2
            for errors, and \c 3 for fatal errors.
        \li \c {--v=1} Increases the logging level beyond what \c {--log-level}
            can, and enables logging debug messages up to verbosity level \c 1.
            A higher number further increases verbosity, but may result in a
            large number of logged messages. Default is \c 0 (no debug messages).
        \li \c {--no-sandbox} disables the sandbox for the renderer and plugin
            processes. Keep in mind that disabling the sandbox might present a
            security risk.
        \li \c {--single-process} runs the renderer and plugins in the same
            process as the browser. This is useful for getting stack traces for
            renderer crashes.
        \li \c {--enable-features=NetworkServiceInProcess} runs networking in
            the main process. This may help firewall management, since only the
            application executable will need to be whitelisted and
            not QtWebEngineProcess. It means losing the security of
            sandboxing of the network service though.
    \endlist

    Alternatively, the environment variable QTWEBENGINE_CHROMIUM_FLAGS can be
    set. For example, the following value could be set to disable logging while
    debugging an application called \e mybrowser:

    \code
    QTWEBENGINE_CHROMIUM_FLAGS="--disable-logging" mybrowser
    \endcode

    QTWEBENGINE_CHROMIUM_FLAGS can also be set using {qputenv} from within the
    application if called before QtWebEngine::initialize().
*/
