With site-per-process enabled a spare renderer process will be created
for use with a future browser or navigation. Consequently the
|extra_info| parameter populated in OnRenderProcessThreadCreated will no
longer be delivered to OnRenderThreadCreated in the expected renderer
process. To avoid confusion these callbacks have been removed completely.
After this change CefRenderProcessHandler::OnWebKitInitialized should
be used for startup tasks in the render process, and OnBrowserCreated
should be used in the render process to recieve |extra_info| passed from
CefBrowserHost::CreateBrowser or CefLifeSpanHandler::OnBeforePopup.
- 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.
This change moves shared resource initialization to a common location and
disables crash reporting initialization in chrome/ code via patch files.
When using the Chrome runtime on macOS the Chrome application window will
display, but web content is currently blank and the application does not
exit cleanly. This will need to be debugged further in the future.
This change adds basic Chrome runtime implementations for CefBrowserContext
and CefBrowserPlatformDelegate. A Chrome browser window with default frame
and styling can now be created using CefBrowserHost::CreateBrowser and some
CefClient callbacks will be triggered via the WebContentsObserver
implementation in CefBrowserHostImpl.
Any additional browser windows created via the Chrome UI will be unmanaged
by CEF. The application message loop will block until all browser windows
have been closed by the user.
This change moves the runtime-specific implementations of CefBrowserHostImpl
methods to CefBrowserPlatformDelegate. Some WebContentsDelegate methods
implemented by CefBrowserHostImpl set state or trigger client callbacks.
Those implementations will likely stay with CefBrowserHostImpl and will
need to be called from the Browser equivalents when using the Chrome runtime.
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.
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.
If a cache_path is specified local_state will now be persisted to a
LocalPrefs.json file. This is necessary because local_state is used to store
the cookie encryption key on Windows.
With this change CefCookieManagerImpl no longer keeps a reference to the
originating CefRequestContextImpl. This means that the CefRequestContextImpl
can be destroyed if all other references are released while the
CefCookieManagerImpl exists. If CefRequestContextImpl destruction results in
the underlying CefBrowserContext being destroyed then the CefCookieManagerImpl's
reference to that CefBrowserContext will be invalidated.
This is the same ownership model introduced with CefMediaRouterImpl in the
previous commit.
Chromium supports communication with media devices on the local network via
the Cast and DIAL protocols. This takes two primary forms:
1. Messaging, where strings representing state information are passed between
the client and a dedicated receiver app on the media device. The receiver
app communicates directly with an app-specific backend service to retrieve
and possibly control media playback.
2. Tab/desktop mirroring, where the media contents are streamed directly from
the browser to a generic streaming app on the media device and playback is
controlled by the browser.
This change adds support for device discovery and messaging (but not
mirroring) with functionality exposed via the new CefMediaRouter interface.
To test: Navigate to http://tests/media_router in cefclient and follow the
on-screen instructions.
This includes the following changes:
- Update usage of surface IDs to match the Aura implementation from the
RWHVAura/Window classes.
- Batch CefBrowserHost::WasResized calls to avoid excessive/unnecessary calls
to SynchronizeVisualProperties.
- Cache the results of CefRenderHandler::GetViewRect after resize and make
RWHVOSR::GetViewBounds the source of truth for all size calculations.
- Fix bounds calculations in CefVideoConsumerOSR with GPU enabled.
Known issues:
- The size passed to OnPaint may be off by 1 pixel in cases where the device
scale factor is not 1 and does not divide evenly into the pixel size. This is
due to the inexact conversion from integer pixel size to integer logical size
for GetViewRect.
Call DesktopWindowTreeHostPlatform::Close after destroying CEF's X11 window
so that objects owned by the WindowTreeHost (Compositor, X11Window, etc) are
properly cleaned up.
The PDF loading documentation in extension_system.cc has be updated to
describe the new code paths.
To support delivery of input events to the mime handler renderer process it is
now necessary to route events via the correct RWHV interface. For Aura-based
platforms (Windows/Linux) this means RWHVAura::On*Event and for macOS this
means RWHVMac::RouteOrProcess*Event. Since Aura uses UI event types these have
become the source of truth on Aura-based platforms with conversion to Web event
types when needed (primarily for OSR).
This change also adds a timeout for CefProcessHostMsg_GetNewBrowserInfo to
avoid a hung renderer process if the guest WebContents route is not
registered via CefMimeHandlerViewGuestDelegate::OnGuestDetached as expected
prior to CefBrowserInfoManager::OnGetNewBrowserInfo being called. This
timeout can be disabled for testing purposes by passing the
`--disable-new-browser-info-timeout` command-line flag.
The `--disable-features=MimeHandlerViewInCrossProcessFrame` command-line
flag can be used for a limited time to restore the previous implementation
based on BrowserPlugin. That implementation will be deleted starting with
the 3897 branch update.
Known issues:
- ExecuteJavaScript calls on the frame hosting the PDF extension will not
be routed to the mime handler renderer process.
- The PDF extension will not load successfully if blocked by
ChromePluginPlaceholder and then manually continued via the "Run this
plugin" context menu option (see https://crbug.com/533069#c41).
Mouse events need to be routed to the correct view and
CefRenderWidgetHostViewOSR::TransformPointToCoordSpaceForView needs to be
properly implemented for
RenderWidgetHostInputEventRouter::DispatchTouchscreenGestureEvent to
transform event position in the target widget.
As of https://crrev.com/9e653328e3 the Views framework will apply the "always
on top" (WS_EX_TOPMOST) style by default to widgets created with TYPE_MENU. CEF
uses this type in CefWindowView::CreateWidget to support child windows that are
not clipped to the parent window bounds (currently indicated by returning a
parent window from CefWindowDelegate::GetParentWindow and setting |is_menu| to
true).
Not setting "always on top" shouldn't be a problem except in cases where some
other window is already "always on top" and the child CefWindow is expected to
overlay that window. For this reason any menus created using ShowMenu will
continue to have the "always on top" style.
This restores the default site isolation mode for Chromium on desktop
platforms. Unit tests have been updated to reflect the new behavior
expectations.
Known behavior changes in CEF are as follows:
- A spare renderer process may be created on initial browser creation or cross-
origin navigation. This spare process may be used with a future cross-origin
navigation or discarded on application shutdown. As a result
CefRenderProcessHandler::OnRenderThreadCreated, which is called shortly after
renderer process creation, can no longer be used to reliably transfer state
for the currently in-progress navigation. Unit tests have been updated to use
the CreateBrowser/OnBeforePopup |extra_info| value for transferring test state
to CefRenderProcessHandler::OnBrowserCreated which will be called in the
correct/expected renderer process.
- Cross-origin navigations will again receive a new renderer process, as
expected. This behavior had briefly regressed in M78 due to the
ProcessSharingWithDefaultSiteInstances feature becoming enabled by default.
- Cross-origin navigations initiated by calling LoadURL in the renderer process
will now crash that process with "bad IPC message" reason
INVALID_INITIATOR_ORIGIN (213). This is a security feature implemented in
Chromium.
- A DevTools browser created using CefBrowserHost::ShowDevTools will receive
the same CefRenderProcessHandler::OnBrowserCreated |extra_info| value that was
set via CreateBrowser/OnBeforePopup for the parent browser.
Mike Wiedenbauer
Masako Toda
Andrei Kurushin
Cristian Amarie
Marshall Greenblatt
lwttai.lu
Alexander Guettler
Vladislav
Dmitry Azaraev
Alex Maitland
Jengerer
rcdrone
Andy Tzeng
Yong Li
elad bahar
Riku Palomäki
Daniel Nitsche
Maksim Sisov