This change replaces existing CefSettings.user_data_path usage with
CefSettings.root_cache_path for better alignment with the Chrome runtime.
All files should now be written inside the root_cache_path directory.
- mac: Xcode 14.0 with macOS SDK 13.0 is now required.
- Remove CefRequestHandler::OnQuotaRequest because persistent quota is no
longer supported (see https://crbug.com/1208141)
Change the default stack size to 8 MiB for 64-bit and 0.5 MiB for 32-bit.
CEF's main thread needs at least a 1.5 MiB stack size in order to avoid
stack overflow crashes. However, if this is set in the PE file then other
threads get this size as well, leading to address-space exhaustion in 32-bit
CEF. A new CefRunWinMainWithPreferredStackSize function uses fibers to switch
the main thread to a 4 MiB stack (roughly the same effective size as the
64-bit build's 8 MiB stack) before running any other code.
This change additionally moves the existing Windows-only functions
CefSetOSModalLoop and CefEnableHighDPISupport from cef_app.h to cef_win.h.
This removes CefSettings.ignore_certificate_errors and
CefBrowserSettings.ignore_certificate_errors. Due to NetworkService
requirements these values must now be configured globally via the
"ignore-certificate-errors" command-line flag.
This change adds support for CEF settings configuration of accept_language_list.
If specified, this value will take precedence over the "intl.accept_languages"
preference which is controlled by chrome://settings/languages.
With the Chrome runtime, Profile initialization may be asynchronous. Code that
waited on CefBrowserContext creation now needs to wait on CefBrowserContext
initialization instead.
The Chrome runtime requires that cookieable scheme information be available
at Profile initialization time because it also triggers NetworkContext creation
at the same time. To make this possible, and to avoid various race conditions
when setting state, the cookieable scheme configuration has been added as
|cookieable_schemes_list| and |cookieable_schemes_exclude_defaults| in
CefSettings and CefBrowserContextSettings. The CefCookieManager::
SetSupportedSchemes and CefBrowserProcessHandler::GetCookieableSchemes methods
are no longer required and have been removed.
This change also modifies chrome to delay OffTheRecordProfileImpl initialization
so that |ChromeBrowserContext::profile_| can be set before
ChromeContentBrowserClientCef::ConfigureNetworkContextParams calls
CefBrowserContext::FromBrowserContext to retrieve the ChromeBrowserContext
and associated cookieable scheme information. Otherwise, the
ChromeBrowserContext will not be matched and the NetworkContext will not be
configured correctly.
The CookieTest suite now passes with the Chrome runtime enabled.
- 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).
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
CefContext implements the public CEF API functions and delegates
the stages of content & service_manager process execution to
CefMainRunner. CEF-specific runtime logic (which may be replaced
with chrome-specific runtime logic) is then delegated to
CefMainDelegate which implements content::ContentMainDelegate.
This restores the behavior prior to revision 438382c. Calling
InitializeSandboxInfo from inside libcef won’t work unless libcef is
statically linked with the executable, so there's no point in doing so.
See the Chromium sandbox docs for background.
The behavior has changed as follows with NetworkService enabled:
- All pending and in-progress requests will now be aborted when the CEF context
or associated browser is destroyed. The OnResourceLoadComplete callback will
now also be called in this case for in-progress requests that have a handler.
- The CefResourceHandler::Cancel method will now always be called when resource
handling is complete, irrespective of whether handling completed successfully.
- Request callbacks that arrive after the OnBeforeClose callback for the
associated browser (which may happen for in-progress requests that are aborted
on browser destruction) will now always have a non-nullptr CefBrowser
parameter.
- Allow empty parameters to CefRequest and CefResponse methods where it makes
sense (e.g. resetting default response state, or clearing a referrer value).
- Fixed a reference loop that was keeping CefResourceHandler objects from being
destroyed if they were holding a callback reference (from ProcessRequest,
ReadResponse, etc.) during CEF context or associated browser destruction.
- Fixed an issue where the main frame was not detached on browser destruction
which could cause a crash due to RFH use-after-free (see issue #2498).
To test: All unit tests pass as expected.
This change adds a new CefSettings.root_cache_path value that must be either
equal to or a parent directory of all CefSettings.cache_path and
CefRequestContextSettings.cache_path values. The sandbox may block read/write
access from the NetworkService to directories that do not meet this requirement.
To test: Run cefclient with a combination of the following flags:
--cache-path=c:\temp\cache
Cache data should be persisted to the specified directory.
--request-context-per-browser
A separate numbered cache directory should be created underneath the
cache-path directory for each new browser instance.
--enable-network-service --disable-extensions
Same tests, but with NetworkService enabled.
Known issues:
- When NetworkService is enabled a C:\temp\cache\cache\Cache directory is
created (should be C:\temp\cache\Cache).
- Windows: 10.0.17763.0 SDK is now required.
- Mac: 10.13 SDK is now required.
- Removed CefRequestContext::ResolveHostCached which is no longer supported by Chromium.
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).
- Crash reporting is enabled and configured using a "crash_reporter.cfg"
file. See comments in include/cef_crash_util.h and tools/crash_server.py
for usage.
Marshall Greenblatt
rcdrone
Petra Öhlin
Alexander Guettler