Existing CefBrowserContext functionality is now split between
CefBrowserContext and AlloyBrowserContext. Runtime implementations of
CefBrowserContext will provide access to the content::BrowserContext and
Profile types via different inheritance paths. For example, the Alloy
runtime uses ChromeProfileAlloy and the Chrome runtime uses ProfileImpl.
This change also renames CefResourceContext to CefIOThreadState to more
accurately represent its purpose as it no longer needs to extend
content::ResourceContext.
This is the first pass in removing direct dependencies on the Alloy
runtime from code that can potentially be shared between runtimes.
CefBrowserHost and CefRequestContext APIs (including CefCookieManager,
CefURLRequest, etc.) are not yet implemented for the Chrome runtime.
Assert early if these API methods are called while the Chrome runtime
is enabled.
As part of introducing the Chrome runtime we now need to distinguish
between the classes that implement the current CEF runtime and the
classes the implement the shared CEF library/runtime structure and
public API. We choose the name Alloy for the current CEF runtime
because it describes a combination of Chrome and other elements.
Shared CEF library/runtime classes will continue to use the Cef
prefix. Classes that implement the Alloy or Chrome runtime will use
the Alloy or Chrome prefixes respectively. Classes that extend an
existing Chrome-prefixed class will add the Cef or Alloy suffix,
thereby following the existing naming pattern of Chrome-derived
classes.
This change applies the new naming pattern to an initial set of
runtime-related classes. Additional classes/files will be renamed
and moved as the Chrome runtime implementation progresses.
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 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.
This attribute is useful for identifying different classes of cast devices
without first requiring a connection (CAST, CAST_AUDIO, CAST_AUDIO_GROUP, etc).
This change also restores the Chromium default values for the
SameSiteByDefaultCookies and CookiesWithoutSameSiteMustBeSecure features. See
https://www.chromium.org/updates/same-site for feature details and rollout
timeline.
The PDF extension will send Range requests when loading large PDF files. For
these cross-origin requests to be allowed (from extension origin to PDF origin)
the CORB checks in URLLoader must be disabled.
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.
