Iterator debugging has been disabled by default (_HAS_ITERATOR_DEBUGGING=0)
for CEF/Chromium builds using clang/LLVM since 2018. Inversely, it is enabled
by default (_ITERATOR_DEBUG_LEVEL=2) for the MSVC Debug build configuration.
In order to minimize configuration-related headaches for MSVC-based clients
we have been building the Debug cef_sandbox.lib with iterator debugging
enabled. Recently, we have identified a number of crashes that may be due to
bugs in current clang/LLVM or MSVC versions but in any case can be resolved by
disabling iterator debugging:
- Crash when loading chrome://sandbox.
- Crash if an application lists libraries that utilize iterators after
cef_sandbox.lib in the linker order.
To resolve these crashes we will now disable iterator debugging by default
for the cef_sandbox.lib builds. Client applications that link cef_sandbox.lib
will now also need to build with iterator debugging disabled by setting
_HAS_ITERATOR_DEBUGGING=0 or _ITERATOR_DEBUG_LEVEL=0 in their project
configuration (this will be done for you if you use cef_variables.cmake from
the binary distribution).
In addition to the crash fixes mentioned above, this change also:
- Reduces the size of the Debug cef_sandbox.lib by ~10MB.
- May result in faster Debug executables (see https://crbug.com/539996).
Chrome currently uses chrome_100_percent.pak, chrome_200_percent.pak,
resources.pak and locales/<locale>.pak files. This change adds CEF
resources to those existing pak files and updates the Alloy runtime to
use them instead of the previous CEF-specific pak files (cef.pak,
cef_100_percent.pak, cef_200_percent.pak, cef_extensions.pak,
devtools_resources.pak) which are no longer generated.
The addition of Chrome resources results in an ~16% (~4.1MB) increase in total
combined pak file size vs. the previous CEF-specific pak files. While a size
increase is not ideal for the Alloy runtime, it seems preferable to the
alternative of distributing separate (and partially duplicated) pak files for
each runtime, which would have added ~9.8MB to the total binary distribution
size.
The Chrome browser can now be hosted in a Views-based application on Mac
(see issue #2969).
To launch a fully-featured Chrome window using cefsimple:
$ open cefsimple.app --args --enable-chrome-runtime
To launch a minimally-styled Views-hosted window using cefsimple:
$ open cefsimple.app --args --use-views [--enable-chrome-runtime]
To launch a fully-styled Views-hosted window using cefclient:
$ open cefclient.app --args --use-views [--enable-chrome-runtime]
Known issues:
- Some Views unit tests are currently failing on Mac.
Windows ARM64 cross-compile requires building Clang x64 binaries. Building both
arm64 and x64 binaries in the same build is not possible when using INCLUDE/LIB
values set via the environment. Instead, allow Chromium to extract the correct
configuration from vcvarsall.bat for populating the environment.[arch] files.
To generate Windows ARM64 builds set the CEF_ENABLE_ARM64=1 environment
variable and pass the "--arm64-build --build-target=cefsimple" command-line
arguments to automate-git.py. We can't build cefclient.exe for ARM64 due to
missing OpenGL library support so build cefsimple.exe instead.
Requires Xcode 12.2 and the MacOS 11.0 SDK. To generate ARM64 builds set
the CEF_ENABLE_ARM64=1 environment variable and replace all usage of
--x64-build with --arm64-build in script command-line arguments.
- CefURLRequest::Create is no longer supported in the renderer process
(see https://crbug.com/891872). Use CefFrame::CreateURLRequest instead.
- Mac platform definitions have been changed from `MACOSX` to `MAC`
(see https://crbug.com/1105907) and related CMake macro names have
been updated. The old `OS_MACOSX` define is still set in code and CMake
for backwards compatibility.
- Linux ARM build is currently broken (see https://crbug.com/1123214).
- Windows: 10.0.19041 SDK is now required.
- macOS: 10.15.1 SDK (at least Xcode 11.2) is now required.
- Remove CefMediaSource::IsValid and CefMediaSink::IsValid which would
always return true.
Running `cefsimple --enable-chrome-runtime` will create and run a
Chrome browser window using the CEF app methods, and call
CefApp::OnContextInitialized as expected. CEF task methods also
work as expected in the main process. No browser-related methods or
callbacks are currently supported for the Chrome window, and the
application will exit when the last Chrome window closes.
The Chrome runtime requires resources.pak, chrome_100_percent.pak
and chrome_200_percent.pak files which were not previously built
with CEF. It shares the existing locales pak files which have been
updated to include additional Chrome-specific strings.
On Linux, the Chrome runtime requires GTK so use_gtk=true must be
specified via GN_DEFINES when building.
This change also refactors the CEF runtime, which can be tested in
the various supported modes by running:
$ cefclient
$ cefclient --multi-threaded-message-loop
$ cefclient --external-message-pump
This change allows the client to directly send and receive DevTools
protocol messages (send method calls, and receive method results and
events) without requiring a DevTools front-end or remote-debugging
session.
This change includes additional supporting changes:
- Add a new CefRequestHandler::OnDocumentAvailableInMainFrame
callback (see issue #1454).
- Add a CefParseJSON variant that accepts a UTF8-encoded buffer.
- Add a `--devtools-protocol-log-file=<path>` command-line flag for
logging protocol messages sent to/from the DevTools front-end
while it is displayed. This is useful for understanding existing
DevTools protocol usage.
- Add a new "libcef_static_unittests" executable target to support
light-weight unit tests of libcef_static internals (e.g. without
requiring exposure via the CEF API). Files to be unittested are
placed in the new "libcef_static_unittested" source_set which is
then included by both the existing libcef_static library and the
new unittests executable target.
- Linux: Remove use_bundled_fontconfig=false, which is no longer
required and causes unittest build errors (see issue #2424).
This change also adds a cefclient demo for configuring offline mode
using the DevTools protocol (fixes issue #245). This is controlled
by the "Offline mode" context menu option and the `--offline`
command-line switch which will launch cefclient in offline mode. When
cefclient is offline all network requests will fail with
ERR_INTERNET_DISCONNECTED and navigator.onLine will return false when
called from JavaScript in any frame. This mode is per-browser so
newly created browser windows will have the default mode. Note that
configuring offline mode in this way will not update the Network tab
UI ("Throtting" option) in a displayed DevTools front-end instance.
The cef_api_hash.h file was previously only updated when the translator tool
was run manually. Forgetting to run the translator tool after changing
include/internal/cef_types*.h files would result in cef_parser.py
incorrectly computing the CEF minor version number for future builds. By
updating this file automatically at build time the number of errors should be
reduced.
Split `gclient sync` into separate `gclient sync --nohooks` and
`gclient runhooks` steps so that we can optionally apply patches
from `runhooks.patch` in-between. This is necessary because the
src/tools/clang/scripts/update.py script is run via a hook and has
dependencies on the VS toolchain scripts which must be patched to
properly consider the GYP_MSVS_VERSION environment variable.
This reverts commit 2cf916e6d5.
This change causes linker errors with third-party projects using VS2019 that also link openssl.
cef_sandbox.lib(err.obj) : error LNK2005: _ERR_get_error already defined in websockets.lib(mbedtls-client.obj)
cef_sandbox.lib(err.obj) : error LNK2005: _ERR_error_string already defined in websockets.lib(ssl_lib.obj)
cef_sandbox.lib(err.obj) : error LNK2005: _ERR_error_string_n already defined in websockets.lib(ssl_lib.obj)
cef_sandbox.lib(err.obj) : error LNK2005: _ERR_free_strings already defined in websockets.lib(ssl_lib.obj)
The optional |extra_info| parameter provides an opportunity to specify extra
information specific to the created browser that will be passed to
CefRenderProcessHandler::OnBrowserCreated() in the render process.
This change adds the d3dcompiler_47.dll version that was included with Windows
SDK 10.0.17134. The newer version of this file included with Windows SDK
10.0.17763 adds a dependency on the Universal C Runtime (api-ms-win-crt-*.dll)
which might not be installed on Windows 7 (requires KB2999226).
Ozone builds can run with different platform backends (Wayland, X11, etc). Usage of the Views framework is required, and the cefclient sample application is not supported.
Example usage:
$ export GN_DEFINES="use_ozone=true"
$ cd /path/to/chromium/src/cef
$ ./cef_create_projects.sh
$ cd /path/to/chromium/src
$ ninja -C out/Release_GN_x64 cefsimple
$ ./out/Release_GN_x64/cefsimple --use-views --ozone-platform=wayland
Binary distributions can be created by passing the `--ozone` flag to make_distrib.py.
This adds *.pak, locales/*.pak , chrome-sandbox, libGLESv2.so, libEGL.so and
swiftshader/*.so to the list of binaries that will be loaded from the libcef.so
directory instead of the executable directory by default.
This change updates make_distrib.py to link in all of libc++ and libc++abi from the Chromium build when generating cef_sandbox.a. This increases the size of the release build of cef_sandbox.a from about 0.5 MB to about 2.0 MB, but it ensures that no C++ symbols are imported by the archive.
Linking cef_sandbox.a with an incompatible C++ library prior to this change could cause undefined behavior in the resulting binary.
To make sure that we do not regress this fix, this change also updates make_distrib.py to verify that no C++ symbols are imported by cef_sandbox.a after it is generated (in a way similar to the way we verify that cef_sandbox.a exports the correct symbols).
This splits out the API hashes from the cef_version.h file which is generated at
build time. Changes to the cef_api_hash.h file are committed to the repo and
represent potentially breaking API changes. This commit history will be used to
calculate the version number.
Known issues:
- The CefLoadCRLSetsFile function needs to be re-implemented (see issue #2497).
- Linux: GTK2 support has been removed. The cefclient sample needs to be updated
to use GTK3 (see issue #2014).